Warum ein SSL-Zertifikat ausstellen, das 2037 abläuft?


11

Wenn ich in Firefox die Verisign Universal Root Certificate Authority ansehe, stelle ich fest, dass sie 2037 abläuft.

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

Warum hat es eine Lebensdauer von 23 Jahren?
Warum sollten sie es nicht so einstellen, dass es früher abläuft? Oder später?


5
Wie die Antwort schon sagt, um zu vermeiden, dass das Stammzertifikat so lange wie möglich ersetzt werden muss. Jemand hat wahrscheinlich einen Ablauf von 25 oder 30 Jahren festgelegt, weil es schmerzhaft ist, diese ersetzen zu müssen, und keinen Nutzen bringt. Die Chancen stehen gut, dass es lange vor Ablauf durch einen mit einem längeren Schlüssel (und möglicherweise einem anderen Krypto-Algorithmus) ersetzt werden muss. Ich mache dasselbe mit unseren internen SSL-Zertifikaten, nur weil ich nie wieder ein Zertifikat für $ [crappy_printer] installieren möchte. Stellen Sie die Ablaufdauer auf länger als die Lebensdauer des Geräts ein und beheben Sie das Problem.
HopelessN00b

Antworten:


13

Der Ablauf wurde im Jahr 2037 festgelegt, um die Möglichkeit zu vermeiden, dass das Datumsproblem des Unix-Jahres 2038 auftritt . Grundsätzlich passen Unix-Daten Anfang 2038 nicht mehr in eine vorzeichenbehaftete 32-Bit-Ganzzahl. Wenn Sie also ein Datum unmittelbar davor verwenden, wird vermieden, dass Code ausgelöst wird, der noch nicht aktualisiert wurde, um das Problem zu beheben.

Stammzertifikate nehmen alle verketteten Zertifikate mit, wenn sie ablaufen. Aus praktischer Sicht müssen sie daher nach verketteten Zertifikaten ablaufen.


7

Wenn ich Ihre Frage verstehe, müssten Ersatzstammzertifikate erneut auf den Clients bereitgestellt werden. Die Chancen stehen also gut, dass ihre Lebensdauer weit genug festgelegt ist, wenn die Wahrscheinlichkeit gering ist, dass das Stammzertifikat abläuft.


4
Wie für "Warum 2037" (oder allgemeiner "Warum nicht eine 100-jährige Ablaufzeit?") - Möglicherweise gibt es technische Einschränkungen , aber zumindest bei einer aktuellen OpenSSL (0.9.8y, auf einem 64-Bit-System). Dies war kein Problem, also ist es wahrscheinlich nur "Ich habe es für
##

1
@ voretaq7 es ist nicht (nur) das Problem bei der Verarbeitung von Bibliotheken, das Problem ist, dass das standardmäßige, gut getestete Format für Daten vor 2038 die UNIX-Epoche verwendet. Wenn Sie Daten danach festlegen möchten, müssen Sie ein anderes Datumsformat verwenden, das möglicherweise nicht von anderen / älteren Bibliotheken unterstützt wird.
Hubert Kario

1
@ HubertKario Ja, ich erinnere mich, dass OpenSSL zuvor "Probleme" mit Daten hinter der roten Linie von Y2038 hatte. Sie scheinen diese Probleme gelöst zu haben, zumindest was meinen Testfall angeht (ich habe ein Zertifikat erstellt, das in 100 Jahren ab heute abläuft und sich nicht beschwert hat) :-)
voretaq7

0

Ich habe definitiv 32-Bit-SSL-Implementierungen gesehen, die auf den 2038-Fehler gestoßen sind, so dass mit ziemlicher Sicherheit "warum 'nur' 2037" erklärt wird.

Warum nicht früher ablaufen? Nun, einer der ursprünglichen Zwecke des Ablaufs war es, ein kompromittiertes Zertifikat zu speichern, das zu lange gültig ist - aber ehrlich gesagt bringt Ihnen das nicht viel. Jetzt haben wir natürlich Listen zum Widerruf von Zertifikaten, sodass wir ein Zertifikat, das uns Probleme bereitet, ziemlich leicht ungültig machen können. Es gibt also keinen wirklichen Zwang, eine kurze Zeit zum Leben zu haben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.