Какие строки разрешены в атрибуте "common name" в сертификате X. 509?

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

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

30
asn.1 security x509

4 ответов

атрибут common 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-имени в атрибут "общее имя" является обычной практикой для сертификатов сервера HTTPS: см. RFC 2818 (сертификаты сервера содержат имя сервера, которое клиент сопоставляет с именем сервера в URL-адресе; обычно для этого предпочтительно расширение имени Alt субъекта, но общее имя несколько более широко поддерживается клиенты.)

48

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

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

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

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

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

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

6

в то время как приведенные выше ответы охватывают то, что вы обычно найдете там, не забывайте, что, поскольку это 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-----
5

какие строки разрешены в атрибуте "common name" в сертификате X. 509?

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

размещение DNS-имени или имени сервера В общем имени (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.

4