Cosa succede quando i certificati più in alto la catena scade prima del mio? (Equifax / GeoTrust)

11

Ho appena acquistato un certificato da RapidSSL. Guardando la catena, ho trovato GeoTrust che è stato firmato da Equifax.

Poi mi sono reso conto che la "Equifax Secure Certificate Authority" scadrà il 2018-08-22 alle 16:42 GMT. Mentre il mio certificato scade il 2018-09-01 alle 01:32 GMT. GeoTrust scadrà il 2022-05-21 alle 06:00. Dando al mio nuovo cert una durata maggiore rispetto a un certificato più in alto nella catena.

Che cosa succederà negli ultimi otto giorni del mio certificato? Non sarà più valido in quanto la catena sarà rotta?

Mi sono imbattuto in questo mentre ho assemblato la catena per far funzionare OSCP in OpenSSL. OpenSSL ha emesso errori quando la mia catena non conteneva Equifax, mentre i browser e altri client sembravano soddisfatti solo della certificazione GeoTrust senza andare oltre la catena. (Presumo che i browser suppongano che GeoTrust sia una CA di primo livello mentre OpenSSL non è felice con loro.)

openssl ocsp -issuer RapidSSL_GeoTrust_Equifax.pem \
  -cert my_rappidssl_cert.pem -url http://rapidssl-ocsp.geotrust.com

(Questo influisce anche su nginx se impostato su certificato di punti metallici OCSP. Fallisce allo stesso modo di OpenSSL con una catena incompleta.)

Posso comunque ottenere gli ultimi otto giorni del mio certificato? O dovrei chiedere un rimborso di 8 giorni?

posta Aeyoun 31.08.2014 - 21:19
fonte

2 risposte

5

I certificati GeoTrust (e RapidSSL) hanno due percorsi di fiducia. Esiste un certificato radice per GeoTrust Global CA valido dal 2002-05-21 al 2022-05-21 e ora diffuso, e anche un certificato "ponte" per la stessa CA valida dal 2002-05-21 al 2018-08-21 concatenato all'autorità di certificazione Secure Equifax che, come avete visto, è valida dal 1998-08-22 al 2018-08-22. Consulta la mia risposta (aggiornata) alla CA corretta per i certificati google . Quindi sì, il tuo certificato non sarà valido per i suoi ultimi giorni se si utilizza il bridge + catena Equifax .

Questo influisce anche sulle risposte OCSP nelle domande senza titolo.

Non ho un certificato rapidssl da testare, ma se chiedo a gtglobal-ocsp.geotrust.com su google-CA, il cert del rispondente è anche sotto GeoTrust Global CA. Se rapidssl-ocsp fa lo stesso, OpenSSL dovrebbe verificare la risposta se il truststore contiene la radice GeoTrust ma non il cert bridge perché ciò può confondere la ricerca della catena - almeno fino ad oggi; 1.0.2 è annunciato per avere cambiamenti nella convalida della catena e non ho ancora visto i dettagli.

Per i server proxy AFAIK, tutti i principali browser si fidano della root di GeoTrust e si collegheranno ad esso. Non so che convalidino le risposte OCSP allo stesso modo (come certs del server) ma lo spero e mi aspetto così.

Ma nota che se il tuo server (è configurato con e) fornisce in handshake il cert bridge, e possibilmente il root - root di Equifax è sempre facoltativo e non necessario nell'handshake, Client OpenSSL (fino a quando sopra) deve avere la radice di Equifax nel truststore, essa non "scoprirà" il percorso alternativo e un miglior trust per la root di GeoTrust, quali browser e forse altri client lo faranno.

    
risposta data 02.09.2014 - 05:13
fonte
1

Dovranno emettere un nuovo certificato prima che il loro non sia più valido. Finché usano la stessa chiave privata per firmare il loro nuovo certificato (radice), il tuo certificato (più lungo) sarà accettato, a condizione che tu abbia fiducia nella loro autorità.

La validità del certificato non è basata sul certificato stesso, ma sulla firma della chiave privata. L'utilizzo della stessa chiave privata per generare un nuovo certificato pubblico, con un nuovo periodo valido, manterrà il trust lo stesso.

    
risposta data 01.09.2014 - 10:48
fonte

Leggi altre domande sui tag