Ein VPN-Zertifikat erneuern, ohne seine Identität zu ändern

Eine Zertifikatserneuerung, die die Identität ändert, ist keine Erneuerung, sondern eine Migration im Gewand eines Wartungstickets. Der Client prüft einen Namen, eine Kette und manchmal einen bestimmten Schlüssel, und alle drei können sich ändern, ohne dass sich das Ablaufdatum ändert. Schreiben Sie vor der Anforderung eines Ersatzes auf, was der Client tatsächlich prüft: den Hostnamen oder die Peer-Identität, den Zertifikatszweck, die Schlüsselrichtlinie und die ausstellende Kette. Die Erneuerung ist Routine oder koordiniert, je nachdem, was davon der Ersatz ändert.

Drei Bedingungen entscheiden über die Form der Erneuerung

Die drei Bedingungen sind, ob etwas das Endzertifikat pinnt, ob sich die Kette ändert und wer sonst den Namen validiert. Beantworten Sie sie aus Sicht des Clients statt aus Bequemlichkeit der CA, denn der Client ist es, der um drei Uhr morgens ausfällt.

Beginnen Sie mit der Prüfung des vorhandenen Zertifikats. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName gibt Subjekt, Aussteller, Gültigkeitsfenster und die Namen aus, für die das Zertifikat tatsächlich gültig ist. Das letzte Feld ist am wichtigsten und wird am häufigsten angenommen: Eine Erneuerungsanforderung, die einen SAN auslässt, auf den der Client angewiesen ist, erzeugt ein Zertifikat, das technisch gültig und funktional falsch ist. Kopieren Sie die SAN-Liste aus dem alten Zertifikat in die Anforderung, statt sie aus dem Gedächtnis neu zu tippen.

Bedingung eins: Pinnt etwas das Endzertifikat

Wenn Clients einer gepflegten CA vertrauen und den Namen validieren, ist eine Erneuerung des Endzertifikats mit einem neuen Schlüssel für sie unsichtbar. Wenn irgendein Client das Endzertifikat, seinen Fingerabdruck oder seinen öffentlichen Schlüssel pinnt, ist der Ersatz ein koordinierter Wechsel mit hartem Umstieg, weil der alte Pin das neue Zertifikat nicht validieren kann.

Finden Sie heraus, in welchem Fall Sie sind, bevor Sie etwas bestellen. Ein Pin, den niemand dokumentiert hat, bleibt ein Pin, wenn er bricht.

Bedingung zwei: Vergleichen Sie die Pins und die Kette

Fingerabdrücke machen den Pin prüfbar: openssl x509 -noout -fingerprint -sha256 -in server.crt beim alten und beim neuen Zertifikat, und openssl x509 -noout -pubkey zum Vergleichen der öffentlichen Schlüssel. Wenn die Client-Konfiguration, ein Mobilprofil oder ein Trust Store eines Geräts einen der beiden Werte enthält, haben Sie einen Pin. Mobile VPN-Profile sind ein häufiges Versteck, weil das Profil einmal verteilt und nie wieder geprüft wird.

Wenn der Ersatz von derselben Zwischenzertifizierungsstelle stammt und der Client sie bereits hat oder abrufen kann, ändert sich auf der Vertrauensseite nichts. Eine neue Zwischenzertifizierungsstelle, ein anderer Aussteller oder eine in falscher Reihenfolge gelieferte Kette verwandeln eine Erneuerung in einen Vertrauenswechsel, und der Fehler sieht wie ein unbekannter Aussteller aus, nicht wie ein abgelaufenes Zertifikat.

Prüfen Sie die Kette, die der Server tatsächlich sendet, mit openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, und verifizieren Sie sie lokal mit openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Wenn Sie das vor der Änderung tun, haben Sie eine Basislinie für den Vergleich danach.

Bedingung drei: Wer sonst validiert den Namen

Ein VPN-Konzentrator, ein Lastverteiler, eine Überwachungssonde, eine RADIUS- oder SAML-Integration und ein Mobilprofil können jeweils ihre eigene Kopie des erwarteten Namens oder des Vertrauensankers halten. Die Erneuerung ist der Moment, in dem diese Kopien auseinanderlaufen, weil sich das Zertifikat ändert und die Kopien nicht.

Listen Sie jeden Verbraucher vor der Änderung auf und entscheiden Sie für jeden, ob er eine Aktualisierung braucht. Der, den Sie vergessen, ist der, der Sie ruft.

Es gibt auch eine Zeitfalle. Prüfen Sie den Beginn der Gültigkeit ebenso wie den Ablauf, denn ein für eine spätere Aktivierung vorbereitetes Zertifikat wird abgelehnt, wenn es zu früh installiert wird, und der Fehler sieht wie ein Uhrproblem aus, nicht wie ein Vorbereitungsproblem. openssl x509 -noout -dates auf der neuen Datei vor dem Ausrollen ist eine Prüfung von zwei Sekunden. Halten Sie auch einen unterstützten Wiederherstellungspfad und die bewährte Konfiguration bereit, damit eine schiefgegangene Erneuerung durch Wiederherstellen des vorherigen Zertifikats und Schlüssels rückgängig gemacht werden kann.

Ausrollen, mit einer frischen Authentifizierung prüfen, dann außer Betrieb nehmen

Ein bestehender Tunnel spiegelt die Validierung wider, die beim Aufbau stattfand, sodass er gesund aussehen kann, während jede neue Verbindung scheitert. Testen Sie mit einer frischen Authentifizierung unter dem tatsächlichen Dienstnamen, den die Clients verwenden.

Schließen Sie die anwendungsspezifische Prüfung ab, die den Nutzer interessiert, und bestätigen Sie die Kettenauslieferung aus Sicht des Clients statt aus Sicht des Servers. Unterdrücken Sie keine Namens- oder Zertifikatsprüfungen, um den Übergang leise zu halten; das verwandelt ein vorübergehendes Kompatibilitätsproblem in ein dauerhaftes.

Nehmen Sie veraltetes Material erst außer Betrieb, nachdem der Rollout geprüft ist, und behandeln Sie einen kompromittierten Schlüssel als völlig anderen Fall: Eine Erneuerung allein widerruft nichts, daher braucht die betroffene Identität den Widerrufs- und Sitzungsverwaltungsprozess der Bereitstellung. RFC 5280 definiert die Zertifikats- und Pfadvalidierungsregeln, auf denen all dies beruht. Halten Sie eine routinemäßige Erneuerung des Endzertifikats getrennt von einem CA-Ersatz, damit von Clients nicht verlangt wird, einem neuen Aussteller ohne Grund zu vertrauen.