Какие строки допускаются в атрибуте "common name" в сертификате X.509? - PullRequest
35 голосов
/ 28 февраля 2011

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

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

Ответы [ 4 ]

53 голосов
/ 28 февраля 2011

Атрибут общего имени в отличительном имени кодируется как:

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; обычно для этого предпочтительнее расширение Subject Alt Name, но общее имя несколько шире поддерживается клиентами).

6 голосов
/ 24 мая 2014

Хотя вышеприведенные ответы охватывают то, что вы обычно найдете там, не забывайте, что, поскольку это 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/emailAddress=test@example.com / favouriteDrink = tequila. Есть много других полей, которые можно поместить в общее имя сертификата.

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

-----BEGIN CERTIFICATE-----
MIIDOzCCAiOgAwIBAgIBCzANBgkqhkiG9w0BAQUFADCBqzEmMCQGA1UEAxMdV2Vz
dHBvaW50IENlcnRpZmljYXRlIFRlc3QgQ0ExEzARBgNVBAgTCkxhbmNhc2hpcmUx
CzAJBgNVBAYTAlVLMR0wGwYJKoZIhvcNAQkBFg5jYUBleGFtcGxlLmNvbTFAMD4G
A1UEChM3V2VzdHBvaW50IENlcnRpZmljYXRlIFRlc3QgUm9vdCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTAeFw0xMTA3MzEyMTAxMTdaFw0yMTA3MjgyMTAxMTdaMFAx
FDASBgNVBAMTC2V4YW1wbGUuY29tMR8wHQYJKoZIhvcNAQkBFhB0ZXN0QGV4YW1w
bGUuY29tMRcwFQYKCZImiZPyLGQBBRMHdGVxdWlsYTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAuCqI3aNbSkRpA9VuGOmeVQ010Oaawsz4tcW2FQChJDOv6PuT
ucy5IijvaVewotDjnuVzPpBVW5EmC8Qapradomhb6FtFPyH/hGSnhLtht3Ln6stJ
ZkAjvr/wjWDy+3Gy/P5r5weUNWVm2AaQgk2xumx49EIXyzwOEHAhqTE7iEECAwEA
AaNIMEYwCQYDVR0TBAIwADA5BggrBgEFBQcBAQQtMCswKQYIKwYBBQUHMAGGHWh0
dHA6Ly9vY3NwLmV4YW1wbGUuY29tOjg4ODgvMA0GCSqGSIb3DQEBBQUAA4IBAQBL
oz035PphO4yUx7FJVaZjxLgTM4wLrcn2ONGm015/ECO+1Uxj3hWb6/EIDDKV/4e8
x0HDF69zyawYLD1th5tBcZLkV/Dat/Tzkt3boLOCGo2I1P+yjqxlb7BZCk7PEs3+
zjWF2hMcXtAwOIrsRuvXp4eTGwigKLAt/H02US/fa2dXFbOnz91V7oH8ZvynIl/n
hpELPzVWX/pBnHEGA9Bi0jviCKuvQisfaJ8XCiA73qH6CkSoZ2fClnrs+pJNj8i6
vtcMx8htn7FsyB3puVww86JSQ+VDKlQkFbPVla/4Aavzwz8djjVYEWwSgm+tw3jB
zUP/k5Aln5cXNo50KOip
-----END CERTIFICATE-----
6 голосов
/ 29 июля 2012

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

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

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

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

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

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

5 голосов
/ 12 февраля 2015

Какие строки разрешены в атрибуте «общего имени» в сертификате X.509?

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

Размещение DNS-имени или имени сервера в общем имени (CN) не рекомендуется для форумов IETF и CA / Browser. Хотя это устарело, в настоящее время это не запрещено. 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.

...