Во-первых, поле «Тема» и расширение «Дополнительное имя субъекта» (сокращенно SAN) - это разные и разные вещи, хотя они оба предназначены для связи с одной и той же сущностью реального мира;ваш заголовок и текст относятся только к первому, а ваш пример - только ко второму.
Технически, поле «Тема» очень гибкое. Оно (как и эмитент) является «отличительным именем» X.501 (DN; не путать с доменным именем), которое состоит из последовательностииз (потенциально наборов) пар тип-значение, где каждый тип определяется идентификатором объекта ASN.1 (сокращенный OID);есть несколько стандартизированных OID, таких как «страна», «местность», «организация» и «commonName», которые очень широко используются, но формат допускает любой OID, а схема OID расширяема - любой может получить выделенную «дугу»и создавать почти неограниченное количество новых OID, с тем важным ограничением, что только программы, которые вы пишете, и системы, которые вы используете, будут знать о новых OID, которые вы создаете, до тех пор, пока другие люди или организации не примут их.Все стандартные DN OID требуют, чтобы их значения были строками, хотя какая именно из нескольких строк поддерживает ASN.1, зависит от того, какой стандарт (ы) вы прочитали и пытаетесь следовать;в частности, смотрите определение типа для DirectoryString;другие OID не обязаны следовать этой практике, но, вероятно, должны облегчить реализацию и использование. SAN несколько менее общий; поддерживает несколько вариантов типа для своих значений, два из которых используют расширяемую схему значений OID +, аналогичную Subject и Issuer, но другие (и более распространенные) вариантыдля SAN более конкретны и ограничены.Изначально технические требования были определены X.509v3, но для использования в Интернете (что не единственное место, где используются сертификаты) и, в некоторой степени, в сетях, совместимых с Интернетом (то есть в интрасетях) или системах,управляющее определение теперь в основном RFC 5280 (плюс связанные биты в некоторых других RFC).Для HTTPS RFC2818 указывает, что если SAN присутствует, клиент (браузер) должен использовать его и игнорировать Subject;некоторые другие протоколы имеют аналогичные (но не всегда идентичные) правила, и RFC6125 рекомендует его для любых новых протоколов.
Однако цель сертификата publickey - передать доверие к ключу дляидентифицируемый субъект (и с различными условиями и ограничениями);это требует, чтобы фактический сертификат идентифицировал субъект достаточно точно для субъектов, которые используют сертификат, которые обычно называются доверяющими сторонами;например, для веб-сайтов HTTPS проверяющими сторонами являются браузеры, действующие от имени людей, получающих доступ к веб-сайтам. Для общедоступной сети (HTTPS и WSS) и на практике для большинства других протоколов SSL / TLS в общедоступной сети эти стандарты устанавливаются CA / Browser Forum .См. 7.1.4 Базовых требований и ссылки на разделы в 3.2.2, особенно в 3.2.2.4 и 3.2.2.5;они обычно требуют, чтобы субъект и SAN содержали, помимо DNS-имен и, возможно, IP-адреса (-ов) , подтвержденных как принадлежащие заявителю (см. далее), только понятные человеку и не вводящие в заблуждение идентификаторыкак название компании(Но см. Ниже.) CA, которые не используются / не пользуются доверием публично, такие как частные CA в рамках бизнеса, агентства, общества или рабочей группы, необязательно должны соблюдать эти правила, хотя их нарушение может вызвать проблемы с программным обеспечением, разработанным дляожидание или предположение, что они следуют.
DNS-имена глобально уникальны. Точнее, Полностью квалифицированные Доменные имена (FQDN), настроенные на соответствующих «авторитетных» DNS-серверах, которые являются единственнымиЕсли вам разрешено получать сертификат от CABforum CA, они уникальны во всем общедоступном Интернете.На самом деле это было одной из целей и задач дизайна DNS с момента его создания в эпоху Рейгана.Однако они обычно выбираются людьми и мнемоническими (для некоторого значения мнемоники), хотя они могут генерироваться автоматически;например, авторы вредоносных программ и операторы ботнетов часто используют автоматически генерируемые и быстро меняющиеся доменные имена для своих систем «управления и контроля», чтобы попытаться предотвратить их обнаружение правоохранительными органами и их отключение.Некоторые (законные) люди также используют длинный случайные или, по крайней мере случайных, как имена поддоменов, чтобы попытаться сохранить их сайты или их часть «скрытый», но это спорно, насколько эффективно это;Я видел несколько Qs (IIRC security.SX и, возможно, webmasters.SX) с эффектом: «Я использовал это случайное доменное имя, которое, как мне кажется, никто не мог догадаться, но оно все еще подвергается атаке / DoSed / обнаружению в поисках ?!»'
IP-адреса также являются глобально уникальными, по крайней мере, «реальными» назначаемыми адресами (не многоадресные, произвольные, для частного использования, локальные ссылки, петлевые и подобные).(Опять же, вы можете получить сертификат CABforum только для назначаемого адреса, если таковой имеется.) Адреса IPv4 назначаются главным образом на основе вашего интернет-провайдера, который является своего рода автоматическим;Адреса IPv6 основаны частично на ISP, а остальные обычно автоматические (псевдослучайные или произвольные, такие как MAC-адрес вашего интерфейса).Они в основном не мнемонические, кроме опытных сетевых инженеров.Однако они, как правило, нестабильны в долгосрочной перспективе, а для мобильных / сотовых / беспроводных сетей или некоторых облаков даже не являются стабильными в краткосрочной перспективе.
Вы не объяснили, почему, по вашему мнению, автоматически генерируемый идентификатор будетиметь какую-либо выгоду.Смогут ли некоторые или все люди узнать, каким должен быть идентификатор конкретного человека, организации или сайта?Как они это сделают, и как вы обеспечите, чтобы информация не могла быть сфальсифицирована или подделана и не устарела?Смогут ли некоторые или все люди подтвердить, что данный идентификатор является неким человеком, объектом или сайтом, с которым они хотят (ed) общаться?Как это лучше, чем идентификатор у нас сейчас?
Один из подходов, который немного напоминает ваш вопрос, заключается в том, что CABforum позволяет выдавать сертификаты EV = Extended Validation (которые являются более дорогостоящими) на адреса «скрытой службы» TOR, то есть адреса '. Onion' ;см. Руководство по EV-руководству Приложение F. (Википедия неправильно описывает бюллетень 144 как добавление этого к Базовой линии, но изменение Базовой линии относится только к revoke .onion сертификатам; изменения к выпуску они находятся в EV.) Поскольку служба TOR активна (программа может взаимодействовать с ней) и постоянно связаны с публичным ключом, центр сертификации может подтвердить, что вы «владеете» ею, и потому что специальный TLD «.onion» являетсяЗарезервированный, CA может создать имя в формате DNS для помещения в CommonName и / или SAN.dnsName, даже если оно не является строго реальным DNS-именем (его нельзя найти на официальном сервере).Этот адрес генерируется автоматически, совсем не мнемонически, и статистически уникален (потому что v3 использует хороший крипто-хэш для данных, которые уже довольно случайны).
Что касается использования командной строки OpenSSL, то это не Q программирования и должно быть оффтопом; многие Qs в основном в других стеках, охватывающих использование OpenSSL для генерации CSR (запросов на подпись сертификатов) и сертификатов, включая самоподписанные (т.е. корневые или псевдокорневые) сертификаты, и сертификаты, которые вы подписываете с помощью своего собственного CA(которые подписаны вами, но НЕ подписаны самостоятельно).Начните с
Как мне создать самозаверяющий сертификат с SubjectAltName с использованием OpenSSL?
Как подписать запрос на подпись сертификата с вашим центром сертификации?
Добавить SAN с личным CA
https://security.stackexchange.com/questions/44251/openssl-generate-different-type-of-self-signed-certificate
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 в CA, по крайней мере, в публичный CA, и запрашиваете произвольную информацию о субъекте и / или SAN, они либо отклонят, либо проигнорируют ее, а затем вставят в сертификат только то, что они (понимают и подтверждают).