Добавьте идентификатор в поле темы SSL-сертификата

Во-первых, поле Subject и расширение Subject Alt[ernative] Name (сокращенно SAN) — это разные и отдельные вещи, хотя они оба предназначены для связи с одним и тем же реальным объектом; ваш заголовок и текст относятся только к первому, а ваш пример только ко второму.

Технически поле Тема очень гибкое. Он (как и Issuer) представляет собой «отличительное имя» X.501 (DN; не путайте с доменным именем), которое состоит из последовательности (потенциально наборов) пар тип-значение, где каждый тип определяется ASN.1 Идентификатор объекта (сокращенно OID); существует несколько стандартизированных OID, таких как «страна», «местность», «организация» и «commonName», которые очень широко используются, но формат допускает любой OID, а схема OID расширяема — любой может получить выделенную «дугу». и создавать почти неограниченное количество новых OID, с важным ограничением, что только программы, которые вы пишете, и системы, которыми вы управляете, будут знать о новых OID, которые вы создаете, до тех пор, пока вы не заставите других людей или организации принять их. Все стандартные OID DN требуют, чтобы их значения были строками, хотя то, какая именно из нескольких строк поддерживает ASN.1, зависит от того, какой стандарт (ы) вы читаете и пытаетесь следовать; в частности, см. определение типа для DirectoryString; другие OID не обязаны следовать этой практике, но, вероятно, должны упростить реализацию и использование. SAN несколько менее распространен; поддерживает несколько вариантов типа для своих значений, два из которых используют расширяемую схему OID+значение, аналогичную Subject и Issuer, но другие (и более распространенные) варианты выбора для SAN являются более конкретными и ограниченными. Технические требования были первоначально определены в X.509v3, но для использования в интернете (это не единственное место, где используются сертификаты) и в некоторой степени в интернет-совместимых сетях (т. плюс соответствующие биты в некоторых других RFC). Для HTTPS RFC2818 указывает, что при наличии SAN клиент (браузер) должен использовать его и игнорировать тему; некоторые другие протоколы имеют похожие (но не всегда идентичные) правила, и RFC6125 рекомендует их для любых новых протоколов.

Однако цель сертификата открытого ключа состоит в том, чтобы передать доверие ключу для идентифицируемого субъекта (и с различными условиями и ограничениями); это требует, чтобы фактический сертификат достаточно точно идентифицировал субъекта для объектов, которые используют сертификат, которые обычно называются доверяющими сторонами; например, для веб-сайтов HTTPS проверяющими сторонами являются браузеры, действующие от имени людей, обращающихся к веб-сайтам. Для общедоступной сети (HTTPS и WSS), и на практике для большинства других протоколов SSL/TLS в общедоступной сети эти стандарты устанавливаются Форум ЦС/браузеров. См. 7.1.4 Базовых требований и упомянутые разделы в 3.2.2, особенно 3.2.2.4 и 3.2.2.5; как правило, они требуют, чтобы субъект и SAN содержали, в дополнение к именам DNS и, возможно, IP-адресам признано принадлежащим заявителю (см. далее) только понятные человеку и не вводящие в заблуждение идентификаторы, такие как название компании. (Но см. ниже.) Центры сертификации, которые не используются или которым не доверяют публично, такие как частные центры сертификации в рамках бизнеса, агентства, общества или рабочей группы, не обязательно должны следовать этим правилам, хотя их нарушение может вызвать проблемы с программным обеспечением, разработанным на ожидания или предположения, которым они следуют.

DNS-имена глобально уникальны. Точнее, Полностью квалифицированный Доменные имена (FQDN), которые настроены на применимых «авторитетных» DNS-серверах, которые являются единственным типом, для которого вам разрешено получать сертификат от ЦС CABforum, создаются уникальными для всей сети. весь общественный интернет. На самом деле это было одной из целей и основных целей разработки DNS, поскольку она была создана в эпоху Рейгана. Однако они обычно выбираются людьми и являются мнемоническими (для некоторого значения мнемонического), хотя они могу генерируются автоматически; например, авторы вредоносных программ и операторы ботнетов часто используют автоматически сгенерированные и быстро меняющиеся доменные имена для своих систем «управления и контроля», чтобы предотвратить их обнаружение правоохранительными органами и их закрытие. Некоторые (законные) люди также используют длинные случайные или, по крайней мере, похожие на случайные имена поддоменов, чтобы попытаться сохранить свои сайты или их части «скрытыми», но вопрос о том, насколько это эффективно, является спорным; Я видел ряд вопросов (IIRC security.SX и, возможно, webmasters.SX) на тему «Я использовал это случайное доменное имя, я думаю, никто никогда не мог догадаться, но оно все еще подвергается атакам/DoS-атакам/обнаруживается при поиске?! '

IP-адреса также являются глобально уникальными, по крайней мере, «реальными» назначаемыми (не многоадресными, произвольными, частными, локальными, петлевыми и т. д.). (Опять же, вы можете получить сертификат CABforum только для назначаемого адреса, если таковой имеется.) Адреса IPv4 назначаются в основном на основе интернет-провайдера, к которому вы подключаетесь, что является своего рода автоматическим; Адреса IPv6 частично основаны на интернет-провайдере, а остальные обычно автоматические (либо псевдослучайные, либо произвольные, например, MAC-адрес вашего интерфейса). В основном они не мнемонические, за исключением опытных сетевых инженеров. Однако они, как правило, не стабильны в долгосрочной перспективе, а для мобильных/сотовых/беспроводных сетей или некоторых облаков даже в краткосрочной перспективе.

Вы не объяснили, почему, по вашему мнению, «автоматически сгенерированный» идентификатор будет полезен. Смогут ли некоторые или все люди узнать, каким должен быть идентификатор конкретного человека, объекта или сайта? Как бы они это сделали, и как бы вы гарантировали, что информация не будет фальсифицирована или подделана, и что она не устарела? Смогут ли некоторые или все люди проверить, что данный идентификатор является принадлежит какому-то лицу, объекту или сайту, с которым они хотят общаться? Чем это лучше, чем id, который у нас есть сейчас?

Один из подходов, который отдаленно напоминает ваш вопрос, заключается в том, что CABforum позволяет выдавать сертификаты EV = расширенной проверки (которые являются более дорогостоящими) на адреса «скрытой службы» TOR, также известные как '.onion' адреса; см. Руководство по EV, Приложение F. (Википедия неправильно описывает бюллетень 144 как добавление этого к базовому уровню, но изменение базового уровня относится только к сертификатам отозвать .onion; изменения в проблема в них внесены в EV.) Поскольку служба TOR активна (программа может общаться с ним) а также постоянно привязан к открытому ключу, ЦС может подтвердить, что вы «владеете» им, и, поскольку зарезервирован специальный TLD «.onion», ЦС может создать имя в формате DNS для помещения в CommonName и/или SAN.dnsName, хотя, строго говоря, это не настоящее DNS-имя (вы не можете найти его на авторитетном сервере). Этот адрес генерируется автоматически, совсем не является мнемоническим и статистически уникальным (поскольку v3 использует хороший крипто-хеш для данных, которые уже достаточно случайны).

Что касается использования командной строки OpenSSL, это не вопрос программирования и должно быть оффтопом; в основном в других стеках есть вопросы много, охватывающие использование OpenSSL для генерации CSR (запросов на подпись сертификата) и сертификатов, включая самозаверяющие (т. е. корневые или псевдокорневые) сертификаты, а также сертификаты, которые вы подписываете с помощью собственного ЦС (которые подписаны вами). , но НЕ самоподписанный). Начните с
Как я могу сгенерировать самозаверяющий сертификат с SubjectAltName с помощью OpenSSL?
Как вы подписываете запрос на подпись сертификата в своем центре сертификации?
Добавьте SAN с частным ЦС
https://security.stackexchange.com/questions/44251/openssl-генерировать-различный-тип-самоподписанного-сертификата
https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate
https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
https://security.stackexchange.com/questions/190905/subject-alternative-name-in-certificate-signing-request-
https://serverfault.com/questions/845766/generating-a-self-signed-cert-with-openssl-that-works-in-chrome-58
https://serverfault.com/questions/845806/how-to-generate-ssl-certificate-having-ca-keys

Но любому сертификату, который вы подписываете сами (включая самоподписанный), вероятно, никто не будет доверять. И если вы отправляете CSR в ЦС, по крайней мере, в общедоступный ЦС, и запрашиваете произвольную информацию о субъекте и / или SAN, они либо отклонят, либо проигнорируют его и вставят в сертификат только то, что они (понимают и) проверяют.