Какие строки допустимы в атрибуте "common name" в сертификате X.509?

В поле общего имени DN сертификата X509, как определено в нотации ASN.1 для OID "2.5.4.3", каковы допустимые значения?

Я знаю, что ограничение составляет до 64 символов, но допустимы ли все символы? Цифры?
Например. допустимы .? Является ли IP-адрес (x.x.x.x) действительной последовательностью для определения ASN?
Разрешено ли доменное имя?

Ответы

Ответ 1

Общий атрибут имени в Distinguished Name кодируется как:

X520CommonName ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-common-name)),
      printableString   PrintableString (SIZE (1..ub-common-name)),
      universalString   UniversalString (SIZE (1..ub-common-name)),
      utf8String        UTF8String      (SIZE (1..ub-common-name)),
      bmpString         BMPString       (SIZE (1..ub-common-name)) }

где ub-common-name равно 64. Последние три кодирования позволяют использовать все Unicode коды (используя UTF-16 для кода точки за пределами 0xFFFF с bmpString); UTF-8 является предпочтительным кодированием (по крайней мере, как утверждают стандарты).

Что касается X.509 (см. RFC 5280), содержимое элементов DN не имеет значения, кроме сравнений с равенством; что означает, что вы можете поместить любую последовательность символов, которые вы хотите, до тех пор, пока вы делаете это последовательно. RFC 5280 требует нечувствительности к регистру для кодированных элементов UTF-8, и это нелегко в общем контексте Unicode: см. Раздел 7.1, который ссылается на RFC 4518 и 3454. Кроме того, "общее имя" часто отображается пользователю (по крайней мере, в системах, использующих сертификаты X.509, которые имеют дисплей и физический пользователь), поэтому вы, вероятно, захотите использовать строку, которая имеет смысл или, по крайней мере, не слишком страшно для человека, и вы можете попытаться избежать нелатинских скриптов.

Включение имени DNS в атрибут "common name" является распространенной практикой для сертификатов сервера HTTPS: см. RFC 2818 (сертификаты сервера содержат имя сервера, которое клиент сопоставляет с именем сервера в URL-адресе, обычно для него предпочтительным является расширение имени темы Alt, но общее имя несколько более широко поддерживается клиентами).

Ответ 2

Если ваша основная проблема заключается в том, чтобы узнать, можете ли вы (или должны) поместить IP-адрес в имя общего имени субъекта, ответ не будет.

Это не относится к формату X.509, а относится к спецификациям, которые говорят, как интерпретировать то, что они читают.

Когда дело доходит до HTTPS, RFC 2818 говорит следующее о IP-адресах:

В некоторых случаях URI указывается как IP-адрес, а не Имя хоста. В этом случае iPAddress subjectAltName должен быть присутствовать в сертификате и точно соответствовать IP в URI.

Это означает, что CN не должен использоваться вообще для IP-адреса и что тип записи SAN должен быть по IP-адресу, а не DNS. (Некоторые браузеры не будут реализовывать это полностью, поэтому они могут быть более терпимыми. Верификатор имени хоста Java по умолчанию будет строгим.)

Рекомендации по проверке подлинности сертификата теперь также определены в RFC 6125, но он считает IP-адреса вне сферы видимости (стоит прочитать этот раздел для аргументов против использования IP-адресов там). Если вы переходите к отрывкам RFC относительно других протоколов, некоторые из них имеют аналогичные ограничения в отношении IP-адресов (например, LDAP).

Ответ 3

В то время как приведенные выше ответы охватывают то, что вы обычно найдете там, не забывайте, что, поскольку это X.509, вы можете на самом деле положить что угодно. В приведенном ниже сертификате используется 0.9.2342.19200300.100.1.5, который является "любимым напитком" (см. http://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html). Openssl понимает это, поэтому общее имя отображается как CN=example.com/[email protected]/favouriteDrink=tequila. Есть много других полей, которые можно поместить в общее имя сертификата.

Вы можете использовать openssl x509 -text, чтобы убедиться, что сертификат отображается, как я описал.

Ответ 4

Какие строки допустимы в атрибуте "common name" в сертификате X.509?

Я не могу ответить на то, что там происходит, но я могу сказать вам, что там не происходит: имена серверов, такие как имена хостов (www.example.com), внутренние имена (например, www) и IP-адреса (например, 127.0.0.1 или 100.100.100.100).

Размещение имени DNS или имени сервера в Common Name (CN) устарело как на IETF, так и на CA/Browser Forums. Хотя он не рекомендуется, он в настоящее время не запрещен. CA/B важен, потому что, что браузеры следуют - браузеры не следуют IETF.

IETF отказался от практики в RFC 6125, раздел 2.3, в то время как CA/B устарел от практики в базовых требованиях, раздел 9.1.1.

Все имена серверов входят в альтернативное имя объекта (SAN). Размещение имен серверов в SAN требуется в соответствии с базовыми требованиями CA/B, раздел 9.2.1. IETF более прощает во время выпуска RFC 5280, но требует его во время проверки в соответствии с разделом 6.4.4 RFC 6125.