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

x509 asn.1 (4)

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 ¿están permitidos todos los caracteres? ¿Dígitos?
Por ejemplo son s permitido? ¿Es una dirección IP (xxxx) una secuencia válida según la definición de ASN?
¿Se permite un nombre de dominio?

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

Realmente no puedo responder lo que ocurre allí, pero puedo decirle lo que no ocurre allí: nombres de servidor, como nombres de host (www.ejemplo.com), nombres internos (como www) y direcciones IP (como 127.0.0.1) o 100.100.100.100).

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

El IETF desaprobó la práctica en RFC 6125, sección 2.3, mientras que el CA / B desaprobó la práctica en los Requisitos de referencia, sección 9.1.1.

Todos los nombres de servidor van en el Nombre alternativo del sujeto (SAN). La colocación de los nombres de los servidores en la SAN es requerida por los Requisitos de línea de base de 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.

El atributo de nombre común en un nombre distinguido 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. Las últimas tres codificaciones permiten el uso de todos los puntos de código Unicode (utilizando UTF-16 para puntos de código más allá de 0xFFFF con bmpString ); UTF-8 es la codificación preferida (al menos las normas así lo dicen).

En lo que respecta a X.509 (ver RFC 5280 ), el contenido de los elementos DN es irrelevante más allá de las comparaciones de igualdad; lo que significa que puede poner cualquier secuencia de caracteres que desee, siempre y cuando lo haga de manera consistente. RFC 5280 exige comparaciones entre mayúsculas y minúsculas para los elementos de nombre codificados en UTF-8, y esto no es fácil en el contexto general de Unicode: consulte 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 los sistemas que usan certificados X.509 que tienen una pantalla y un usuario físico), por lo que es probable que desee usar una cadena que sea significativa o al menos no demasiado aterradora para un humano, y puede intentar evitar los scripts no latinos.

Poner un nombre DNS en el atributo "nombre común" es una práctica común para los certificados de servidor HTTPS: consulte RFC 2818 (los certificados de servidor contienen el nombre del servidor, que el cliente compara con el nombre del servidor en la URL; normalmente, la extensión del Asunto Alt Name es preferido para eso, pero el nombre común es algo más ampliamente soportado por los clientes).

Si bien las respuestas anteriores cubren lo que normalmente encontrarás allí, no lo olvides, porque esto es X.509, en realidad puedes poner casi cualquier cosa allí. El siguiente certificado, por ejemplo, utiliza 0.9.2342.19200300.100.1.5, que es "bebida favorita" (consulte 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/[email protected]/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 lo describí.

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

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

Cuando se trata de HTTPS, RFC 2818 dice lo siguiente sobre 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, iPAddress debe estar presente en el certificado y debe coincidir exactamente con la IP en el URI.

Esto significa que el CN no debe utilizarse en absoluto para una dirección IP, y que el tipo de entrada SAN debe ser una dirección IP, no DNS. (Algunos navegadores no lo implementarán completamente, por lo que podrían ser más tolerantes. El verificador de nombre de host predeterminado de Java será estricto).

Las mejores prácticas para la verificación de identidad de certificado también se definen ahora en RFC 6125 , pero considera que las direcciones IP están fuera del alcance (vale la pena leer esta sección para conocer los argumentos en contra de usar direcciones IP allí). Si revisa los extractos de RFC con respecto a otros protocolos , algunos tienen restricciones similares con respecto a las direcciones IP (por ejemplo, LDAP).