Browser che incidono sui fusi orari e sul rinnovo dei certificati di sicurezza

Question

Browser che incidono sui fusi orari e sul rinnovo dei certificati di sicurezza

#1 da (4 voti)
#2 da (2 voti)

2

Venerdì sera (JST) stavo rivedendo il sito web di una società che si occupava di commercio di valute. Nessun problema. Il sabato mattina provo a tornare al sito, ma sia Chrome che Safari dicono che non si fidano del certificato di sicurezza. Ho controllato e la convalida era scaduta. Strano.

Poistamattinahovisitatodinuovoilsitoeilcertificatoèvalidoepossoentrare(siasuChromesiasuSafari)

Poihonotatounastranezza.

Conilcertificatofallito,l'avvisodicevacheilcertificatoèscadutosabato13agosto2016alle8:59:59JST.

Maconilcertificatovalidodioggil'avvisodicecheilcertificatoèvalidodal13agosto201600:00:00GMT.

Hocontrollatoladifferenzadiorarioe8:59:59JSTè23:59:59GMT(nota:ilRegnoUnitoèinorarioestivo)

Si tratta di un problema con il modo in cui i browser controllano la validità del certificato? Assumono sempre che il tempo di scadenza è 23:59:59 e il tempo di validità è 00:00:00, ma non verificare mai se vi è una differenza di fuso orario o una differenza di ora legale?

web-browser certificate-authority

posta mycowan 14.08.2016 - 00:49

fonte

2 risposte

Leggi altre domande sui tag web-browser certificate-authority

È sicuro trasferire una chiave privata RSA sulla rete? Quanto è sicura la compilazione automatica della password del browser nativo?

score 4 · Answer 1

La mia ipotesi è che il certificato del sito Web sia effettivamente scaduto, quindi ne hanno acquistato uno nuovo e lo ha sostituito prima che tu verificassi di nuovo.

Quando Comodo emette un certificato, l'ora "valida da" viene retrodatata alle 00:00:00 UTC del giorno in cui è stata emessa e l'ora "valida fino a" è di 23:59:59 il giorno in cui scade. Quindi il nuovo certificato potrebbe essere stato rilasciato in qualsiasi momento della giornata del 13 agosto.

(Questa è la particolare politica di Comodo. Altre CA lo gestiscono in modo diverso.)

È un po 'tardi per provare a dimostrarlo ora, ma puoi cercare il dominio su uno strumento come Censys e vedere se hanno una copia del certificato di ieri.

Linea temporale ipotetica:

2016-08-12 21:00:00 JST (2016-08-12 12:00:00 UTC): visita il sito web con successo. Il vecchio certificato scadrà a 2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC), 11:59:59 da ora. I sysadmin non hanno idea.
2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC): il vecchio certificato scade. Tutti gli amministratori di sistema sono addormentati.
2016-08-13 10:00:00 JST (2016-08-13 01:00:00 UTC): visiti il sito Web e ricevi un errore. Il vecchio certificato è scaduto 01:00:01 fa. Gli amministratori di sistema sono ancora addormentati.
2016-08-13 15:00:00 JST (06-08-2016 06:00:00 UTC): gli amministratori di sistema si svegliano, si accorgono di averlo espulso e scramble per sostituire il certificato. Il nuovo è valido a partire dal 2016-08-13 09:00:00 JST (00:00:00 UTC).
2016-08-14 07:00:00 JST (20-08-2016 22:00:00 UTC): visiti nuovamente il sito web. Il nuovo certificato è, ovviamente, valido.

score 2 · Answer 2

never check if there is a time zone difference or a summertime difference?

Il tempo di scadenza di un certificato è impostato in GMT (UTC). Quello che vedi è la differenza di come i diversi browser presentano il tempo di scadenza del certificato, ad esempio Safari lo trasforma in JST (probabilmente il tuo fuso orario locale) mentre Chrome lo mostra in GMT. Il controllo si effettua confrontando entrambi i tempi all'interno dello stesso fuso orario, cioè confrontando di solito l'ora locale con GMT prima di controllare.

Do they always assume the expiry time is 23:59:59 and the validity time is 00:00:00,

Il tempo di scadenza ha una precisione di secondi e i browser lo controllano in questo modo. Inoltre, alcune CA potrebbero impostare la scadenza alle 23:59:59, altre no.