VPN-Zertifikat noch nicht gültig: drei Ursachen, eine Prüfreihenfolge

Sie öffnen den Client, wählen das Profil, das Sie seit Monaten nutzen, und er bleibt mit "certificate is not yet valid" stehen. An Ihrer Anmeldung hat sich nichts geändert, und der Vertrauensspeicher ist wahrscheinlich in Ordnung: Das im Handshake vorgelegte Zertifikat trägt ein Gültigkeitsfenster, das später beginnt als der Zeitpunkt, den der Prüfer verwendet. Drei verschiedene Situationen erzeugen genau diese Meldung, und sie erfordern unterschiedliche Maßnahmen. Die Reihenfolge unten sagt Ihnen, welche Sie haben, bevor Sie eine Uhr oder eine Zertifikatsdatei anfassen.

Welche der drei Ursachen Sie vor sich haben

Die erste Ursache ist lokal: Das prüfende Gerät hat eine Uhr, die früher steht als das Startdatum des Zertifikats. Sie sehen das bei Hardware mit leerer CMOS-Batterie, bei virtuellen Maschinen, die aus einem alten Snapshot wiederhergestellt wurden, bei Geräten, die lange genug ausgeschaltet waren, um die Zeit zu verlieren, und in Netzen, in denen ausgehendes NTP blockiert ist und niemand es bemerkt hat. Das Zertifikat kann völlig gültig sein und trotzdem auf diese Weise scheitern.

Die zweite Ursache gehört zum Aussteller, weil das Zertifikat tatsächlich in der Zukunft beginnt: früh ausgestellt, mit einer ausdrücklichen Startzeit erzeugt oder als Teil eines Aktivierungsschritts signiert, der noch nicht gelaufen ist. Die dritte Ursache kostet die meiste Zeit, weil das Blatt aktuell ist, während ein anderes Zertifikat in der vorgelegten Kette es nicht ist, sodass der Fehler Material nennt, das Sie nie installiert haben.

Eine Frage trennt sie. Folgt der Fehler dem Gerät oder dem Dienst? Zwei Rechner im selben Netz, die sich unterschiedlich verhalten, deuten auf Uhren. Wenn jeder Client auf dieselbe Weise scheitert, deutet das auf das Fenster des Zertifikats und die Kette dahinter.

Lesen Sie das Fenster aus dem Zertifikat, das tatsächlich vorgelegt wurde

Prüfen Sie keine PEM-Datei, die von einem früheren Rollout übrig geblieben ist; fragen Sie den Dienst nach der Kette, die er gerade sendet. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts gibt jedes Zertifikat der Kette aus. Speichern Sie den Block, der Sie interessiert, und führen Sie openssl x509 -noout -subject -issuer -dates aus; das letzte gibt notBefore und notAfter aus, und diese beiden Werte entscheiden die Sache. Unter Windows zeigen der Zertifikatsdialog der Verbindung und certutil -dump für eine exportierte Datei dieselben Felder.

Lesen Sie beide Enden des Fensters, nicht nur den Anfang. Ein Zertifikat, das in zwei Stunden öffnet, und eines, das in zwei Stunden schließt, scheitern mit unterschiedlichen Meldungen und betreffen unterschiedliche Teams. Notieren Sie, welches Zertifikat der Fehler nennt — Blatt, Zwischenzertifikat oder Wurzel —, denn das entscheidet, ob auf der Clientseite überhaupt etwas zu reparieren ist.

Sie können das Fenster auch testen, ohne darauf zu warten. Die Prüfung akzeptiert eine ausdrückliche Zeit: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem bewertet die Kette zu diesem Zeitstempel. Führen Sie es mit der aktuellen Zeit aus, um den Fehler nachzustellen, dann mit der Startzeit des Zertifikats, um zu bestätigen, dass dieselbe Kette besteht, sobald das Fenster öffnet. RFC 5280 definiert das Gültigkeitsfeld und die Regel, dass ein Zertifikat außerhalb davon nicht verwendet werden darf, und genau diese Regel hat Ihr Client gerade durchgesetzt.

Ihre Uhr oder deren

Vergleichen Sie die Geräteuhr mit dem Beginn des Zertifikats in UTC, aus einer Quelle, der Sie vertrauen. date -u gibt den Zeitpunkt, und timedatectl status auf einem systemd-Host meldet auch, ob die Uhr synchronisiert ist. Unter Windows zeigt w32tm /query /status die aktuelle Quelle und die letzte erfolgreiche Synchronisierung. Eine in der Taskleiste angezeigte Zeitzone ist eine Anzeigewahl, keine falsche Uhr; der Prüfer vergleicht UTC-Zeitpunkte.

Wenn die Uhr nachgeht, synchronisieren Sie neu und testen Sie erneut, bevor Sie irgendein Zertifikatsmaterial ändern. Ein Gerät, das Minuten oder Stunden daneben liegt, weist jedes kürzlich ausgestellte Zertifikat zurück, auf das es trifft, nicht nur einen Dienst, sodass eine Erklärung mit einem einzigen Dienst meist die falsche ist. Wenn die Uhr richtig und synchronisiert ist, hören Sie auf, das Gerät anzusehen: Das Fenster gehört dem Aussteller, und keine lokale Einstellung sollte angepasst werden, damit es besteht.

Diese Tabelle ist die ganze Entscheidung. Die Uhr auf das zu stellen, was das Zertifikat erwartet, ist keine Reparatur, und Zeitsprüfungen abzuschalten ist auch keine, weil beides den Zustand verbirgt, der den Fehler erzeugt hat.

Warum die Kette scheitert, während das Blatt in Ordnung aussieht

Erneuerte Blätter und Ersatzzwischenzertifikate werden meist zusammen ausgeliefert, und sie landen nicht immer im selben Moment. Ein Dienst kann ein neues Blatt senden, das von einem Zwischenzertifikat signiert ist, dessen eigenes Fenster später beginnt, oder ein älteres Zwischenzertifikat unter einem frischen Blatt weiter ausliefern. So oder so scheitert die Kette, während die eigenen Daten des Blatts vernünftig aussehen.

Lastverteilte Endpunkte machen daraus statt kaputt inkonsistent. Wenn ein neuer Versuch gelingt oder ein Netz funktioniert und ein anderes nicht, notieren Sie, welcher Peer geantwortet hat und welche Kette er gesendet hat, bevor Sie Einstellungen ändern. openssl s_client gibt die verbundene Adresse aus, sodass einige Versuche zeigen, ob jeder Knoten dieselbe Kette ausliefert.

Reparaturwege, die die Prüfung intakt lassen

Ein Uhrproblem wird am Gerät behoben, während die Prüfung eingeschaltet bleibt. Ein Zertifikatsproblem behebt der Betreiber mit Material, das für ein Fenster ausgestellt wurde, das jetzt bereits enthält. Keine Clienteinstellung macht ein noch nicht gültiges Zertifikat gültig; die Flags, die Zeitsprüfungen überspringen, gibt es, damit Sie eine Diagnose bestätigen, nicht damit Sie sie ausliefern.

Wenn das Zertifikat für eine geplante Aktivierung bereitgestellt wird, folgen Sie dem Umstellungsplan. Installieren Sie es, wenn sein Fenster öffnet, oder nutzen Sie das Überlappungsverfahren, das der Anbieter dokumentiert, statt es früh zu installieren und Benutzern beizubringen, Warnungen wegzuklicken. Warnungen, die Menschen zu ignorieren lernen, kosten mehr als eine kurze Verzögerung.

Testen Sie schließlich so erneut, wie der Fehler auftrat: eine neue Sitzung, derselbe Client, die Ressource, die Sie wirklich brauchen. TLS-Bibliotheken können eine geprüfte Kette für die Lebensdauer einer Verbindung zwischenspeichern, und eine fortgesetzte Sitzung prüft sie nicht unbedingt erneut, sodass eine alte Sitzung nach der Reparatur weiter scheitern oder nach einer Regression weiter funktionieren kann. Eine Datei, die sich in einem Betrachter öffnet, beweist nur, dass die Datei lesbar ist; ein abgeschlossener Handshake beweist, dass die Kette validiert.

Bevor Sie das Ticket schließen, bestätigen Sie vier Dinge: die UTC-Zeit und den Synchronisierungszustand des fehlerhaften Geräts, notBefore und notAfter jedes Zertifikats in der vorgelegten Kette, dieselbe Kette von einem zweiten Client und den Namen, den der Fehler dem Zertifikat gibt. Wenn die Uhr richtig ist und das Fenster sich noch nicht geöffnet hat, ist der Rest Betreibersache, und der richtige Schritt auf Ihrer Seite ist, auf das Fenster zu warten, statt die Prüfung zu schwächen.