Pourquoi émettre un certificat SSL qui expire en 2037?

11

Dans Firefox, si je consulte l'autorité de certification racine universelle Verisign, je remarque qu'elle expire en 2037.

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

Pourquoi a-t-il une durée de vie de 23 ans?
Pourquoi ne le feraient-ils pas expirer plus tôt? Ou plus tard?

ssl-certificate certificate-authority

— user3298687
source

5

Comme le dit la réponse, pour éviter d'avoir à remplacer le certificat racine aussi longtemps que possible. Quelqu'un a probablement imposé une échéance de 25 ou 30 ans, car c'est pénible de devoir les remplacer, et cela n'apporte aucun avantage. Les chances sont que bien avant son expiration, il devra être remplacé par un autre avec une clé plus longue (et peut-être un algorithme de cryptage différent, d'ailleurs). Je fais de même avec nos certificats SSL internes, juste parce que je ne veux jamais avoir à installer un autre certificat sur $ [crappy_printer]. Définissez la période d'expiration sur une durée supérieure à la durée de vie de l'appareil et le problème est résolu.

— HopelessN00b

13

L'expiration a été fixée en 2037 pour éviter la possibilité de rencontrer le problème de date Unix année 2038 . Fondamentalement, au début de 2038, les dates Unix ne tiennent plus dans un entier 32 bits signé, donc l'utilisation d'une date juste avant évite de déclencher tout code non encore mis à jour pour résoudre le problème.

Les certificats racine emportent avec eux tous les certificats chaînés à leur expiration. D'un point de vue pratique, ils doivent donc expirer après tout certificat chaîné.

— Brian
source

7

Si je comprends votre question, les certificats racine de remplacement devraient être redéployés vers les clients. Les chances sont donc que leur durée de vie soit suffisamment éloignée là où il y a peu ou pas de chance que le certificat racine expire.

— MikeAWood
source

4

Quant à "Why 2037" (ou plus largement "Why not a 100 year expiration time?") - Il peut y avoir des contraintes techniques en jeu , mais au moins sur un OpenSSL récent (0.9.8y, sur un système 64 bits) ce n'était pas un problème donc c'est probablement juste "je l'ai fait durer pendant ## ans")

— voretaq7

1

@ voretaq7 ce n'est pas (seulement) le problème avec les bibliothèques de traitement, le problème est que le format standard et bien testé pour les dates avant 2038 utilise l'époque UNIX. Si vous souhaitez définir des dates après cela, vous devez utiliser un format de date différent, et il peut ne pas être pris en charge par d'autres bibliothèques / anciennes.

— Hubert Kario

1

@HubertKario Oui, je me souviens qu'OpenSSL avait précédemment un "problème" avec des dates dépassant la ligne rouge Y2038. Ils semblent avoir résolu lesdits problèmes, du moins en ce qui concerne mon cas de test (j'ai créé un certificat qui expire 100 ans à partir d'aujourd'hui et il ne s'est pas plaint) :-)

— voretaq7

0

J'ai certainement vu des implémentations SSL 32 bits s'exécuter dans le bogue 2038, ce qui explique presque certainement "pourquoi 'seulement' 2037".

Quant à pourquoi ne pas expirer plus tôt? Eh bien, l'un des objectifs initiaux de l'expiration était de sauver un certificat compromis valide trop longtemps - mais en toute honnêteté, cela ne vous rapporte pas grand-chose. Maintenant, bien sûr, nous avons des listes de révocation de certificats, de sorte que nous pouvons assez facilement invalider un certificat qui nous cause des problèmes, donc il n'y a pas vraiment de contrainte d'avoir un court laps de temps à vivre.

— Tom Newton
source