¿Hay una orden de respetar en el campo subjectName al crear un certificado x509 con el comando OpenSSL? En otras palabras, ¿cuáles son todas las posibilidades de mostrar el nombre de sujeto del certificado x509 en OpenSSL?
En el campo subjectDN de un certificado, está el propietario del certificado nombre distinguido , que es nominalmente ordenado. Su definición realmente es un SEQUENCE de SET de elementos de nombre, por lo que es una secuencia ordenada de conjuntos de elementos desordenados. Es bastante raro tener varios elementos de nombre en el mismo conjunto (lo he visto hecho para poner el Nombre común, el Nombre y el Apellido juntos, como tres elementos con el mismo nivel).
El orden de los elementos en un nombre distinguido se relaciona con la razón por la que se definieron dichos nombres en primer lugar: como una ruta de indexación en el Directorio. El Directorio puede visualizarse como una estructura mundial que hace referencia a todo; Su principal problema es que nunca existió. Existen versiones locales del Directorio, diluidas y diluidas: se denominan servidores LDAP (o "Active Directory" en el mundo Windows). Para algunos usos, es posible que desee considerar el orden de los campos en el subjectDN si el software que usa el certificado realmente se conectará a algún servidor LDAP y usará el subjectDN para obtener más información sobre El titular del certificado. Este es un caso raro. De hecho, incluso en Windows + Active Directory (que está muy interesado en el uso de LDAP), cuando un certificado se asigna a una cuenta, la cuenta generalmente se encuentra con el UPN , que es un tipo de nombre específico de Microsoft ubicado no en subjectDN , pero en una extensión de Nombre alternativo del sujeto; El subjectDN se usa realmente solo para fines de visualización (el elemento de Nombre común del subjectDN se muestra al usuario humano).
Cuando se utilizan certificados para servidores SSL, el orden de los elementos de nombre en un nombre distinguido no tiene ningún significado específico. El issuerDN de un certificado debe ser idéntico al subjectDN del certificado de la CA que lo emitió (y, en particular, debe tener los elementos en el mismo orden), pero más allá de eso no hay ningún orden a seguir. El cliente SSL (navegador web) extraerá (como máximo) el elemento de nombre común, independientemente de dónde aparezca en la secuencia, e ignorará todos los demás elementos.
Para ver el orden de los elementos de nombre en subjectDN , puede usar openssl asn1parse como lo indica @StackzOfZtuff en su respuesta. Hacer que el problema sea más confuso es RFC 4514 (que reemplaza al anterior RFC 2253): esta es la representación estándar de un DN en una cadena, para ser utilizada en el contexto LDAP. Por alguna razón, la representación de cadena se definió para enumerar los elementos de nombre en el orden en reversa :
Otherwise, the output consists of the string encodings of each
RelativeDistinguishedName in the RDNSequence (according to Section
2.2), starting with the last element of the sequence and moving
backwards toward the first.
Sin embargo, al usar openssl x509 -text -noout para mostrar el contenido de un certificado, OpenSSL mostrará las cadenas subjectDN y issuerDN en un formato que está muy cerca de RFC 4514, excepto que sigue el orden de aparición de los elementos de nombre en el certificado codificado, no el "orden inverso" exigido por RFC 4514.
Los "Nombres" también pueden aparecer en la extensión de Nombres alternativos del sujeto . Esa extensión está definida para contener un SEQUENCE de GeneralName , es decir, está técnicamente ordenada. Sin embargo, nada en X.509 adjunta ninguna semántica al orden de los nombres; de hecho, esta extensión está definida para usar un SEQUENCE OF y no un SET OF principalmente porque la codificación de un SET OF con reglas DER es más costosa (hay que ordenar los nombres lexicográficamente). El orden en el que aparecen los diversos nombres en una extensión SAN no tiene influencia alguna en la validez de un certificado, y no debería cambiar nada en el comportamiento de la aplicación.
Por supuesto, cualquier software dado puede fallar en hacer las cosas correctamente. En un contexto SSL, es común que aparezcan varios nombres de tipo dNSName en una extensión SAN: el navegador escaneará todos los nombres hasta que encuentre un nombre que coincida con el nombre del servidor esperado (como aparece en la URL) , o se queda sin nombres, lo que ocurra primero; este comportamiento, implícitamente, no depende en última instancia del orden de los nombres.
Puede mostrar nombres alternativos de sujeto (SAN) con OpenSSL como este:
(Estoy usando el certificado de Facebook.com como ejemplo).
Utilizando el subcomando x509 :
$ openssl x509 -in facebook-cert.pem.cer -noout -text | grep 'Subject Alternative Name' -A1
X509v3 Subject Alternative Name: DNS:*.facebook.com, DNS:facebook.com, DNS:*.fb.com, DNS:fb.com, DNS:*.fbsbx.com, DNS:*.fbcdn.net, DNS:*.xx.fbcdn.net, DNS:*.xy.fbcdn.net, DNS:*.xz.fbcdn.net, DNS:*.m.facebook.com, DNS:*.messenger.com, DNS:messenger.com
Utilizando el subcomando asn1parse :
$ openssl asn1parse -in facebook-cert.pem.cer -i -dump | nl | sed '74,85p' -n
74 452:d=5 hl=3 l= 175 prim: OCTET STRING 75 0000 - 30 81 ac 82 0e 2a 2e 66-61 63 65 62 6f 6f 6b 2e 0....*.facebook. 76 0010 - 63 6f 6d 82 0c 66 61 63-65 62 6f 6f 6b 2e 63 6f com..facebook.co 77 0020 - 6d 82 08 2a 2e 66 62 2e-63 6f 6d 82 06 66 62 2e m..*.fb.com..fb. 78 0030 - 63 6f 6d 82 0b 2a 2e 66-62 73 62 78 2e 63 6f 6d com..*.fbsbx.com 79 0040 - 82 0b 2a 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a ..*.fbcdn.net..* 80 0050 - 2e 78 78 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a .xx.fbcdn.net..* 81 0060 - 2e 78 79 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a .xy.fbcdn.net..* 82 0070 - 2e 78 7a 2e 66 62 63 64-6e 2e 6e 65 74 82 10 2a .xz.fbcdn.net..* 83 0080 - 2e 6d 2e 66 61 63 65 62-6f 6f 6b 2e 63 6f 6d 82 .m.facebook.com. 84 0090 - 0f 2a 2e 6d 65 73 73 65-6e 67 65 72 2e 63 6f 6d .*.messenger.com 85 00a0 - 82 0d 6d 65 73 73 65 6e-67 65 72 2e 63 6f 6d ..messenger.com
Lea otras preguntas en las etiquetas certificates openssl x.509