Это не очень хорошая идея в целом. Цель сертификата - позволить клиенту убедиться, что он действительно общается с нужным сервером, а не, например, с злоумышленником типа «человек посередине». То, как это происходит (несколько упрощенно), заключается в том, что сертификат включает в себя ключ publi c сервера и доменное имя («общее имя») сервера, с которым клиент собирался связаться. Затем сертификат подписывается другим сертификатом того же типа и содержания и т. Д., Пока цепочка не достигнет сертификата, который не должен быть подписан другим, поскольку он уже является доверенным клиентом (он находится в доверенных корнях). например, список вашей ОС).
Самоподписанный сертификат не имеет этой цепочки подписей, он называется самоподписанным, потому что сертификат, используемый для его подписи, сам по себе. Клиент не может проверить сертификат (если, конечно, он явно не указан как доверенный). Это означает, что злоумышленник может подделать (олицетворять) ваш API, самостоятельно подписав другой сертификат для того же доменного имени, но с другой парой ключей. Это может позволить украсть учетные данные или обслуживать поддельные данные. Обратите внимание, что злоумышленник может также передавать информацию, введенную пользователем (все сделанные запросы), в реальный API, поэтому ответы (также полученные злоумышленником вначале, но переданные жертве) могут легко выглядеть очень реальными без дополнительной справочной информации.
Это может (теоретически) быть решено путем закрепления сертификата, но в случае клиента Javascript это будет сложно (если вообще возможно). HPKP может показаться решением, но HPKP не будет работать с самозаверяющим (не проверяемым) сертификатом. Я не уверен, что Javascript имеет соответствующий уровень доступа к сертификату сервера для реализации закрепления.
Даже если вы внедрили закрепление, самозаверяющий сертификат также не может быть отозван. Подумайте, что произойдет, если вы обнаружите компрометацию ключа TLS, используемого для https, в вашем домене api. У вас не будет возможности отозвать ключ, поэтому клиенты по-прежнему будут принимать злоумышленника MitM, обслуживающего скомпрометированный ключ.
Это требует больших усилий, и вы могли бы реализовать нечто нестандартное, трудно получить правильное и подвержен ошибкам.
Или вы можете просто использовать бесплатный сертификат letsencrypt для api.domain.com, для которого вся необходимая инфраструктура и настройка уже выполнены в основном домене. :)