Perché emettere un certificato SSL che scade nel 2037?

11

In Firefox, se visualizzo l'autorità di certificazione radice universale Verisign, noto che scade nel 2037.

( Settingsscheda -> advanced-> view certificates-> VeriSign Universal Root Certification Authority-> View.)

Perché dura 23 anni?
Perché non dovrebbero impostarlo per scadere prima? O più tardi?

ssl-certificate certificate-authority

— user3298687
fonte

5

Come dice la risposta, per evitare di dover sostituire il certificato radice il più a lungo possibile. Qualcuno probabilmente ha una scadenza di 25 o 30 anni, perché è un dolore doverli sostituire e non offre alcun vantaggio. Le probabilità sono che molto prima che scada, dovrà essere sostituito da uno con una chiave più lunga (e forse un algoritmo crittografico diverso, per quella materia). Faccio lo stesso con i nostri certificati SSL interni, solo perché non voglio mai dover installare un altro certificato su $ [crappy_printer]. Impostare il periodo di scadenza su una durata superiore al dispositivo e risolvere il problema.

— HopelessN00b,

13

La scadenza è stata fissata nel 2037 per evitare la possibilità di incorrere nel problema della data di Unix dell'anno 2038 . Fondamentalmente all'inizio del 2038 le date Unix non rientrano più in un numero intero a 32 bit con segno, quindi l'utilizzo di una data appena prima evita di innescare qualsiasi codice non ancora aggiornato per risolvere il problema.

I certificati di root portano con sé tutti i certificati concatenati quando scadono, quindi dal punto di vista pratico devono scadere dopo eventuali certificati concatenati.

— Brian
fonte

7

Se capisco la tua domanda, i certificati di root sostitutivi dovrebbero essere ridistribuiti ai client. Quindi le probabilità sono che la loro vita è abbastanza lontana da dove ci sono poche o nessuna possibilità che il certificato di root scada.

— MikeAWood
fonte

4

Per quanto riguarda "Why 2037" (o più in generale "Why not a scadenza di 100 anni?") - Potrebbero esserci vincoli tecnici in gioco , ma almeno su un recente OpenSSL (0.9.8y, su un sistema a 64 bit) questo non era un problema, quindi probabilmente è solo "L'ho fatto durare per ## anni")

— voretaq7,

1

@ voretaq7 non è (solo) il problema con l'elaborazione delle librerie, il problema è che il formato standard, ben collaudato per le date precedenti al 2038, utilizza l'epoca UNIX. Se si desidera impostare le date successive, è necessario utilizzare un formato data diverso e potrebbe non essere supportato da altre / vecchie librerie.

— Hubert Kario,

1

@HubertKario Sì, ricordo che OpenSSL aveva precedentemente avuto un "problema" con le date oltre la linea rossa Y2038. Sembrano aver risolto questi problemi, almeno per quanto riguarda il mio caso di test (ho creato un certificato che scade tra 100 anni da oggi e non si è lamentato) :-)

— voretaq7,

0

Ho sicuramente visto implementazioni SSL a 32 bit nel bug 2038, quindi quasi sicuramente rappresenta "perché" solo "2037".

Per quanto riguarda perché non scadere prima? Bene, uno degli scopi originali della scadenza era quello di salvare una certificazione compromessa valida per troppo tempo - ma in tutta onestà ciò non ti fa guadagnare molto. Ora ovviamente abbiamo elenchi di revoche di certificati, quindi possiamo facilmente invalidare un certificato che ci sta causando problemi, quindi non c'è vera costrizione a vivere in breve tempo.

— Tom Newton
fonte