Certificato verificato utilizzando due percorsi diversi

Question

Certificato verificato utilizzando due percorsi diversi

#1 da (6 voti)

4

StartSSL ha un certificato intermedio che usano per firmare i loro certificati EV: sub.class4.server .ca.pem . L'emittente di questo certificato è indicata da openssl x509 per essere / C = IL / O = StartCom Ltd./OU=Secure Firma digitale del certificato / CN = Autorità di certificazione StartCom . Ciò corrisponde al certificato che distribuiscono come CA principale: ca.pem .

Tuttavia, Firefox / Mozilla include due certificati con quell'oggetto. Uno è uguale al certificato distribuito da StartSSL. L'altro ^{(allegato sotto)} è verificabilmente diverso; per esempio, il numero di serie del primo è 1, mentre il numero seriale di quest'ultimo è 45. Modifica: Dopo ulteriori ricerche, si scopre che questo è lo stesso del certificato che StartSSL distribuisce come ca-sha2.pem .

Se utilizzo openssl verify per controllare sub.class4.server.ca.pem contro ca.pem , funziona:

% openssl verify -CAfile ca.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

È interessante notare che, se lo controllo con il certificato di Firefox / Mozilla, funziona ancora:

% openssl verify -CAfile ca-ff.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

Per assicurarmi che qualcos'altro non entrasse lì per oscurare i miei risultati, l'ho provato contro un certificato che sapevo essere sbagliato:

% openssl verify -CAfile ca-wrong.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

Questo lascia due possibilità: o openssl verify non sta controllando la firma effettiva e fa affidamento esclusivamente sull'oggetto dell'emittente (probabilmente perché lo sto usando in modo errato), o in qualche modo questo certificato può essere verificato con due certificati diversi.

Per verificare la prima possibilità, ho creato un certificato autofirmato con le stesse informazioni sull'emittente e l'ho usato per verificare il certificato intermedio:

% openssl verify -CAfile ca-fake.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

Quindi sembra che openssl verify non sia facilmente interpretabile.

Poi mi è venuto in mente che due certificati diversi potevano verificare lo stesso certificato figlio se usavano la stessa chiave RSA, e ho scoperto che il modulo della chiave pubblica riportato per i due certificati è lo stesso.

Riguarda che StartCom abbia apparentemente usato la stessa chiave RSA per due certificati diversi? Mi sembra una cattiva idea, ma sono solo un dilettante.

Per comodità per chiunque stia esaminando questo, ecco il certificato aggiuntivo che Firefox ha:

digital-signature certificates certificate-authority rsa x.509

posta wfaulk 27.03.2014 - 17:58

fonte

1 risposta

Leggi altre domande sui tag digital-signature certificates certificate-authority rsa x.509

Acquisizione sottodominio a causa di record impropri Quanto è difficile leggere la memoria flash da un chip?

score 6 · Accepted Answer

Per quanto riguarda X.509, non ci sono assolutamente problemi nell'avere più certificati con la stessa chiave pubblica. Il processo di validazione è descritto in tutti i dettagli qui ; in poche parole, si verifica che:

ogni certificato della catena è attualmente valido (per quanto riguarda le date di inizio e di fine validità);
la firma su ciascun certificato è corretta per il contenuto del certificato e la chiave pubblica nella CA di emissione;
il DN dell'emittente di ciascun certificato corrisponde al DN soggetto della sua CA emittente;
tutte le estensioni di certificato (norme sui certificati, vincoli di nome ...) sono corrette.

Avere la stessa chiave pubblica in due certificati distinti non è un problema. Ogni certificato asserisce un legame tra una chiave pubblica e un'identità . Se hai dieci certificati che asseriscono lo stesso legame, tanto meglio.

In pratica, avere diversi certificati con lo stesso nome e chiave è il normale risultato dei rinnovi. Alla scadenza di un certificato, potresti voler conservare la stessa coppia di chiavi per il nuovo certificato.

Nel tuo caso, la situazione è leggermente diversa perché i certificati coinvolti sono certificati radice, cioè non certificati "reali": non sono emessi da una CA; sono navi convenienti per ancore fidate . Tuttavia, un confronto di entrambi i certificati (con openssl x509 -text -noout -in ca.pem ) rivela il motivo per cui ce ne sono due (ed è un motivo molto povero): questo fa parte di un anatema sovrastante previsto su SHA-1. Infatti, un certificato di root è spesso autofirmato (poiché esiste un campo non facoltativo per una firma nel formato X.509) e un algoritmo di firma inizia con una funzione di hash. Il certificato "vecchio" (il file ca.pem di StartSSL) dichiara una firma con SHA-1, mentre il "nuovo" certificato (dalle interiora di Firefox) utilizza una firma basata su SHA-256.

Un'altra differenza è che il "nuovo" certificato non include URL per il download di CRL, che è corretto poiché un certificato di root, per definizione, non può essere revocato dalla sua CA di emissione.

Oltre al numero di serie, all'algoritmo di hash e all'URL per il download di CRL, i due certificati sono identici; contengono lo stesso nome, la chiave pubblica e le date di validità. Penso che il rifiuto cieco, sistematico, eccessivamente zelante di SHA-1 sia l'unità principale qui. Questa è una cattiva ragione perché:

SHA-1 non è ancora rotto, in particolare per le firme, che lavorano più sulle pre-immagini che sulle collisioni.
La firma su un certificato radice è inutile, quindi non importa se la funzione hash dichiarata è SHA-1, SHA-256, MD5 o FOOBAR42.