OpenSSL x509: esiste un ordine nei campi subjectName?

Nel campo subjectDN di un certificato, c'è il proprietario del certificato nome distinto , che è nominalmente ordinato. La sua definizione è in realtà un SEQUENCE di SET degli elementi del nome, quindi è una sequenza ordinata di insiemi di elementi non ordinati. È abbastanza raro avere diversi elementi del nome nello stesso set (l'ho visto fare per mettere insieme il nome comune, il nome e il cognome, come tre elementi con lo stesso livello).

L'ordinamento di elementi in un nome distinto si riferisce al motivo per cui tali nomi sono stati definiti in primo luogo: come un percorso di indicizzazione nella Directory. La Directory può essere immaginata come una struttura mondiale che fa riferimento a tutto; il suo problema principale è che in realtà non è mai esistito. Esistono versioni locali ridotte e diluite della directory: sono chiamate server LDAP (o "Active Directory" nel mondo Windows). Per gli usi alcuni , potresti voler ricordare l'ordine dei campi in subjectDN se il software che utilizza il certificato si connetterà realmente a qualche server LDAP e utilizzerà subjectDN per ottenere più dati su il proprietario del certificato. Questo è un caso raro. Infatti, anche in Windows + Active Directory (che è molto appassionato di utilizzare LDAP), quando un certificato viene mappato su un account, l'account si trova in genere con UPN , che è un tipo specifico di nome di Microsoft che non si trova in subjectDN , ma in un'estensione di nome alt soggetto; il subjectDN viene quindi realmente utilizzato solo a scopo di visualizzazione (l'elemento Nome comune di subjectDN viene mostrato all'utente umano).

Quando si usano i certificati per i server SSL, l'ordine degli elementi del nome in un nome distinto non ha alcun significato specifico. Il issuerDN di un certificato deve essere identico al subjectDN del certificato della CA che lo ha emesso (e in particolare deve avere gli elementi nello stesso ordine), ma oltre a ciò non esiste un ordine da seguire. Il client SSL (browser Web) estrarrà (al massimo) l'elemento Nome comune, indipendentemente da dove appare nella sequenza, e ignorerà tutti gli altri elementi.

Per vedere l'ordine degli elementi del nome in subjectDN , puoi usare openssl asn1parse come indicato da @StackzOfZtuff nella sua risposta. Rendere il problema più confuso è RFC 4514 (che sostituisce il vecchio RFC 2253): questa è la rappresentazione standard di un DN in una stringa, da utilizzare nel contesto LDAP. Per qualche motivo, la rappresentazione della stringa è stata definita per elencare gli elementi del nome in reverse order:

   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.

Tuttavia, quando si usa openssl x509 -text -noout per visualizzare il contenuto di un certificato, OpenSSL mostrerà subjectDN e issuerDN come stringhe in un formato che è molto vicino a RFC 4514, tranne che segue l'ordine di comparsa degli elementi del nome nel certificato codificato, non il "reverse order" richiesto da RFC 4514.

I "nomi" possono anche apparire nella estensione dei nomi alternativi dei soggetti . Tale estensione è definita per contenere un SEQUENCE di GeneralName , cioè è tecnicamente ordinato. Tuttavia, nulla in X.509 attribuisce alcuna semantica all'ordine dei nomi; infatti, questa estensione è definita per utilizzare un SEQUENCE OF e non un SET OF principalmente perché codificare un SET OF con le regole DER è più costoso (devi ordinare i nomi lessicograficamente). L'ordine in cui appaiono i vari nomi in un'estensione SAN non ha alcuna influenza sulla validità di un certificato e dovrebbe non modificare nulla nel comportamento dell'applicazione.

Naturalmente, qualsiasi software potrebbe non funzionare correttamente. In un contesto SSL, è comune che diversi nomi di tipo dNSName appaiano in un'estensione SAN: il browser esegue la scansione di tutti i nomi finché non trova un nome che corrisponde al nome del server previsto (come appare nell'URL) o esaurisce i nomi, a seconda di cosa viene prima; questo comportamento, implicitamente, non dipende in ultima analisi dall'ordine dei nomi.

È possibile visualizzare Subject Alternative Names (SAN) con OpenSSL come questo:
(Sto usando il certificato Facebook.com come esempio.)

Uso del sottocomando 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

Uso del sottocomando 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