¿Qué cadenas están permitidas en el atributo "nombre común" en un certificado X.509?

Question

En el campo de nombre común del DN de un certificado X509, como se define en la notación ASN.1 para OID "2.5.4.3", ¿cuáles son los valores permitidos?

Sé que el límite es de hasta 64 caracteres, pero ¿se permiten todos los caracteres? ¿Dígitos?
P. ej. son . s permitido? ¿Es una dirección IP (x.x.x.x) una secuencia válida según la definición de ASN?
¿Se permite el uso de un nombre de dominio?

Answer 1

El atributo nombre común en un nombre completo se codifica como:

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)) } 

donde ub-common-name es 64. Los últimos tres codificaciones permitir el uso de todos los Unicode puntos de código (usando UTF-16 para puntos de código más allá de 0xFFFF con bmpString); UTF-8 es la codificación preferida (al menos los estándares lo dicen).

En lo que concierne a X.509 (ver RFC 5280), los contenidos de los elementos de DN son irrelevantes más allá de las comparaciones de igualdad; lo que significa que puede poner cualquier secuencia de caracteres que desee, siempre que lo haga de manera consistente. RFC 5280 ordena comparaciones insensibles a mayúsculas/minúsculas para elementos de nombre codificados UTF-8, y esto no es fácil en el contexto general de Unicode: ver la sección 7.1, que enlaza con RFC 4518 y 3454. Además, el "nombre común" se muestra con frecuencia al usuario (al menos en sistemas que usan certificados X.509 que tienen una pantalla y un usuario físico), por lo que probablemente desee utilizar una cadena que sea significativa o al menos no demasiado aterradora. para un ser humano, y puede tratar de evitar los scripts no latinos.

Poner un nombre DNS en el atributo "nombre común" es una práctica común para certificados de servidor HTTPS: ver RFC 2818 (los certificados del servidor contienen el nombre del servidor, que el cliente coincide con el nombre del servidor en la URL; La extensión Alt Name es preferida para eso, pero el nombre común es un poco más ampliamente compatible con los clientes).

Answer 2

Si su problema principal es saber si puede (o debería) poner una dirección IP en el Nombre común del DN del sujeto, la respuesta es no.

Esto no está relacionado con el formato X.509, sino con las especificaciones que dicen cómo interpretar lo que leen.

Cuando se trata de HTTPS, RFC 2818 dice lo siguiente acerca de las direcciones IP:

En algunos casos, el URI se especifica como una dirección IP en lugar de un nombre de host . En este caso, el iPAddresssubjectAltName debe ser presente en el certificado y debe coincidir exactamente con la IP en el URI.

Esto significa que el CN ​​no debe usarse en absoluto para una dirección IP, y que el tipo de entrada SAN debe ser por dirección IP, no por DNS. (Algunos navegadores, no se implementan esta totalmente, por lo que podrían ser más tolerante. El nombre de host predeterminado de Java verificador será estricta.)

Las mejores prácticas para la verificación de identidad certificado también se definen ahora en RFC 6125, pero considera IP addresses out of scope (Vale la pena leer esta sección para obtener argumentos contra el uso de direcciones IP allí). Si pasa por el excerpts of RFCs regarding other protocols, algunos tienen limitaciones similares con respecto a las direcciones IP (por ejemplo, LDAP).

Answer 3

Si bien las respuestas anteriores cubren lo que generalmente encontrarás allí, no olvides que, debido a que es X.509, puedes poner prácticamente cualquier cosa allí. El certificado a continuación, por ejemplo, usa 0.9.2342.19200300.100.1.5 que es 'bebida favorita' (Ver http://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html). Openssl entiende esto, por lo que el nombre común se muestra como CN=example.com/emailAddress=test@example.com/favouriteDrink=tequila. Hay muchos otros campos que se pueden poner en el nombre común del certificado.

Puede usar openssl x509 -text para verificar que el certificado se muestra como he descrito.

-----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----- 

Answer 4

Lo cuerdas están permitidos en el “nombre común” atributo en un certificado X.509?

Realmente no puedo responder a lo que pasa allí, pero te puedo decir lo que hace no entrar ahí: nombres de servidor, como nombres de host (www.example.com), nombres internos (como www) y direcciones IP (como 127.0.0.1 o 100.100.100.100).

La colocación de un nombre DNS o nombre de servidor en el Nombre común (CN) ha quedado obsoleta tanto en IETF como en CA/Browser Forums. Aunque desaprobado, actualmente no está prohibido. El CA/B es importante porque eso es lo que siguen los navegadores: los navegadores hacen no siguen el IETF.

IETF desaprobó la práctica en RFC 6125, sección 2.3, mientras que CA/B desaprobó la práctica en los Requisitos de línea de base, sección 9.1.1.

Todos los nombres de servidor van en el Nombre alternativo del sujeto (SAN). La colocación de nombres de servidor en la SAN es requerida por los requisitos de la línea de base CA/B, sección 9.2.1. El IETF es más indulgente durante la emisión con RFC 5280, pero lo requiere durante la validación en la sección 6.4.4 de RFC 6125.