Perché il certificato scaricato mostra una data di scadenza diversa rispetto allo stesso certificato se visualizzato online?

Question

Perché il certificato scaricato mostra una data di scadenza diversa rispetto allo stesso certificato se visualizzato online?

#1 da (7 voti)
#2 da (7 voti)

6

Questa è una sorta di follow-up alla mia domanda precedente Quali campi in un certificato sospetto dovrei guardare?

Chrome ha appena presentato l'icona di avviso sul certificato presentato dal link (inserisco sempre l'URL in) perché non è stato possibile verificare il CRL . Per mancanza di qualcosa di meglio da fare, ho scaricato la catena di certificati e sono stato sorpreso di vedere una voce scaduta contro il certificato intermedio nella catena.

Il certificato intermedio è stato rilasciato a www.verisign.com/CPS Incorp. di Ref. RESPONSABILITÀ LTD. (C) 97 Verisign

I campi di validità su questo certificato d / l sono i seguenti

Da: 17/04/1997

A: 08/01/2004

Se visualizzato nel browser, questo certificato mostra una data di fine del 25/10/2016

Speriamo che non sia motivo di preoccupazione, ma non posso fare a meno di chiedermi ...

Perché il certificato scaricato mostra una data di scadenza diversa rispetto allo stesso certificato online?

P.S. Ho provato a scaricare nuovamente la catena di certificati in un'altra posizione e a vedere ancora una data di scadenza del 2004.

public-key-infrastructure tls

posta Everyone 05.01.2012 - 13:06

fonte

2 risposte

Leggi altre domande sui tag public-key-infrastructure tls

Cifra chiave SSH esistente Qualcuna organizzazione usa le smart card oltre a quelle militari?

score 7 · Answer 1

Dan Kamisky ha scoperto e scritto un blog su un problema molto simile tre mesi fa con Facebook. Ha rintracciato il problema su Facebook mettendo in campo alcuni bilanciatori del carico di prova basati sui vecchi certificati VeriSign scaduti. Come sempre con i suoi scritti, l'investigazione è ben fatta e presentata in una lettura eccellente. La linea di fondo nel suo caso è che non c'era nessuna minaccia. Il post di blog è un ottimo libro link blog

score 7 · Answer 2

In SSL / TLS, il server invia il suo certificato come parte di una catena. Il client dovrebbe accertare la chiave pubblica del server e usarlo per terminare l'handshake.

Il modo in cui il client deve "indovinare" e "convalidare" la chiave pubblica del server è del tutto suo; la catena di certificati inviata dal server è, nominalmente, puramente indicativa. Si tratta di: "hey, client, devi sapere (ed essere sicuro di) la mia chiave pubblica, questo insieme di certificati potrebbe essere di qualche utilità per te". Come per specifica SSL / TLS , la catena inviata dal server dovrebbe essere appropriata per la convalida, e un cliente avrebbe il diritto di interrompere la connessione se la catena esatta inviata dal server non viene convalidata; ma nulla afferma che il client deve usare quella catena esatta e nessuna altra.

Nel tuo caso, è plausibile che Chrome, dopo aver convalidato il certificato del server, trovi che uno dei certificati è scaduto, ma riesce a convalidare il certificato del server utilizzando altri certificati che Chrome conosce (o li ha già visti da un'altra connessione precedente da qualche parte, o li conosce intrinsecamente). Nota che conoscere un certificato non è lo stesso di fidarsi di un certificato; non vi è alcun problema di sicurezza nell'accesso a qualche grande spazio potenzialmente insicuro per i certificati CA intermedi, poiché le firme su questi certificati extra verranno comunque verificate in fase di utilizzo (i certificati CA intermedi sono certificati ematici non ).

Per riassumere, il server di Facebook fa una cosa non valida, come da RFC 5246, in quanto invia una catena di certificati che è ovviamente non valida. Lo stesso RFC 5246 consente ancora ai client di ripristinare in modo trasparente, a patto che possano applicare patch alla catena con certificati più aggiornati, e questo è ciò che fa Chrome.