Il cert root manca di CN

Question

Il cert root manca di CN

#1 da (3 voti)

0

La CA interna di un'azienda ha emesso un certificato di firma radice (non esiste un certificato intermedio che funge da firmatario) in cui il DN contiene solo C = US e O = company_name e nessun altro campo DN.

Il certificato firmato da questa radice viene utilizzato per un'istanza di IBM MQ, quindi le cose che si connettono non stanno confrontando il CN con l'URI. L'unico valore SAN presente corrisponde all'etichetta cert nel keystore che IBM imposta automaticamente a ibmwebspheremq[qmgrname] in modo che SAN wold non corrisponda all'URI, al nome di QMgr o a qualsiasi altra cosa che un richiedente di connessione si aspetterebbe.

Le app JEE che si collegano a questo server utilizzando una varietà di provider JEES non si lamentano.
La convalida di OpenSSL utilizzando s_client ha esito positivo.
IBM GSKit non riesce a convalidare il certificato personale nel KDB locale (il formato dell'archivio di chiavi di IBM) utilizzando questo firmatario. L'errore cita An invalid basic constraint extension was found con GSKM_VALIDATIONFAIL_SUBJECT che cita IssuerName ed Emittente ma mostra valori identici.

Mi chiedo se questo DN, in particolare il CN mancante, sia considerato non conforme. O, più precisamente, funziona ovviamente con alcuni provider di crittografia, ma dovrei aspettarmi che fallisca con una convalida più rigorosa?

ibm certificates certificate-authority

posta T.Rob 25.10.2018 - 18:55

fonte

1 risposta

Leggi altre domande sui tag ibm certificates certificate-authority

I principali contendenti sostituiscono le password? MS Active Directory vs OpenId Connect?

score 3 · Accepted Answer

I'm wondering whether this DN, in particular the missing CN, is considered non-compliant.

Non conforme rispetto a cosa? Diamo un'occhiata ad alcune cose con cui potrebbe essere o non essere compatibile.

X.509

Soddisfa le specifiche X.509: da RFC 5280 sezione 4.2.1.6 Oggetto ( corsivo mio):

If the subject is a CA (e.g., the basic constraints extension, as discussed in Section 4.2.1.9, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty [X.500] distinguished name [DN] matching the contents of the issuer field.

e O=company_name,C=US è un DN X.500 valido, quindi non vi è alcuna non conformità.

TLS 1.2

Non ho familiarità con back-of-my-hand con RFC 5246 , ma sembra indicare che il server i certificati devono essere convalidati dal cliente, ma lascia tutto al fornitore per decidere come farlo. Quindi non ci sono nemmeno le non conformità.

CA / Forum browser

I Requisiti di base CA / B forniscono i criteri per i certificati che sono accettabili per un browser Web senza generare errori.

Non citerò direttamente perché è un documento lungo con molti riferimenti agli attributi Subject e SAN, ma questo corrisponde alla comprensione che il nome di dominio completo (FQDN) deve essere nel DN o in una SAN . Quindi abbiamo trovato qualcosa che il tuo cert IBM non è conforme!

Riepilogo: se si è tentato di connettersi a una pagina HTTPS protetta da tale certificato, il browser utilizza correttamente una serie di errori perché tale certificato non è conforme ai requisiti di base CA / B.

Per qualsiasi altro utilizzo di TLS, è assolutamente soddisfacente. Infatti, se lo scopo è certificare che si tratta di un server IBM gestito da company_name , controllare la CA radice e una SAN specifica per IBM sembra un modo appropriato per farlo! (Con questo obiettivo, importa quale sia l'hostname della scatola o quale URL hai usato per accedervi?)