Nome comune non valido quando si utilizza un certificato SAN

Question

Ho generato un certificato per un server interno accessibile anche esternamente. Secondo this SO rispondere al CN e i campi SAN si completano a vicenda e quindi di conseguenza ho impostato il CN su server.domain.local e nella SAN ho DNS: server.domain.tld

Tuttavia, con Chrome almeno , Posso passare a server.domain.tld (voce SAN) senza errori ma ottengo un errore di disallineamento di nome comune su server.domain.local (CN)

Si tratta di un errore di implementazione in NSS su Chrome o ho fatto Qualcosa non va? Devo avere sia server.domain.local e server.domain.tld nel campo SAN?

Answer 1

.. il CN ed i campi SAN completano a vicenda ..

Questo è vero solo nel caso generale PKI, ma specifici protocolli avere un comportamento diverso. Il RFC rilevanti per il controllo del certificato HTTPS è RFC2818 (o versione successiva RFC6125) in cui si afferma:

If a subjectAltName extension of type dNSName is present, that MUST 
be used as the identity. Otherwise, the (most specific) Common Name 
field in the Subject field of the certificate MUST be used. Although 
the use of the Common Name is existing practice, it is deprecated and 
Certification Authorities are encouraged to use the dNSName instead. 

Ciò significa che, se si dispone di una sezione SAN deve contenere tutti i nomi, perché il CN non verrà controllato.

Answer 2

NC ei campi SAN completano a vicenda e così di conseguenza ho impostato il CN per server.domain.local e nel SAN ho DNS: server.domain.tld

No (ma quel post è un po 'vecchio adesso).

Inserire un nome DNS è il nome comune (CN) è deprecato da IETF e CA/Browser Forum. È necessario posizionare tutti i nomi DNS in Subject Alternate Name (SAN). Utilizzare il CN per un nome descrittivo come "Esempio LLP" poiché è visualizzato all'utente.

In base ai CA/Browser Baseline Requirements (BR), un nome DNS nel CN ​​deve essere presente anche nella SAN. Vedi CA/B BR, Section 9.2.

---

Chrome, almeno, posso individuare server.domain.tld (ingresso SAN) senza errori ma ottengo un errore comune nome non corrispondente a server.domain.local (CN)

Chrome è correttamente rifiutando il certificato seserver.domain.localè presente nel CN, ma non è presente nella SAN. È una violazione del CA/B BR se non è presente in entrambi.

---

Dovrei avere sia server.domain.local e server.domain.tld nel campo SAN

Sì, posizionare entrambi i nomi DNS nella SAN. Non inserire un nome DNS nel CN. Usa la CN per un nome descrittivo.

---

Per completezza, CA/B sta per CA e browser. Hanno il loro piccolo club chiuso e hanno il loro insieme di politiche per il rilascio dei certificati. Non aspettarti che i browser facciano cose come specificato nei documenti IETF.

E se si convalidano i certificati X509 utilizzati in natura emessi da una CA membro di CA/B, è necessario convalidare utilizzando CA/B BR e non i documenti IETF.

Answer 3

La domanda originale ha avuto risposta, ma mi piacerebbe confutare un punto espresso in una delle risposte.

L'utilizzo della CN per un nome descrittivo, per quanto attraente e ragionevole per me, non è supportato dai CA CA/B. Nella versione precedente dei CA/B BR, si trattava della sezione 9.2.2, ma sembra essersi spostata di recente. https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf

---

7.1.4.2.2. Soggetto Distinguished Name Fields

a. Campo certificato: oggetto: commonName (OID 2.5.4.3) Obbligatorio/facoltativo: Obsoleto (Scoraggiato, ma non vietato)

Contenuto: Se presente, questo campo DEVE contenere un indirizzo IP singolo o Nome dominio completo che è uno dei valori contenuti nell'estensione subjectAltName del certificato.

---

Rispettosamente, --obivon