SoftEther ServerCertSet: die erneuerte Kette mit vpncmd importieren

Certbot meldet eine erfolgreiche Erneuerung, die Dateien auf der Platte tragen neue Datumsangaben, und Clients treffen weiterhin die alte Identität an. SoftEther hält sein SSL-Serverzertifikat in seiner eigenen Konfiguration auf Serverebene, daher ändert eine neue Datei auf der Platte nichts, bis das Blattzertifikat und sein Schlüssel importiert sind. Die folgende Reihenfolge deckt einen manuellen Import, einen Wrapper, der nach jeder Erneuerung läuft, und eine Prüfung ab, die liest, was der Listener tatsächlich präsentiert. Jeder Schritt hinterlässt Belege, die Sie nach der nächsten Erneuerung vergleichen können.

Eine erneuerte Datei ändert die Serveridentität nicht

Ausstellung und Deployment sind getrennte Ereignisse mit getrennten Fehlermodi. Der ACME-Client schreibt Dateien in ein Lineage-Verzeichnis und vermerkt Erfolg; SoftEther verwendet weiter das Zertifikat, das zuletzt in seine Konfiguration geladen wurde. Ein Exit-Status von null beschreibt daher die Dateien, nicht den Dienst, und beide können voneinander abweichen, solange niemand hinsieht. Behandeln Sie den Import als den Deployment-Schritt und die Erneuerung als dessen Eingabe.

Diese Unterscheidung erklärt auch den verwirrenden Halbfehler: Das alte Zertifikat funktioniert bis zu seinem Ablauf weiter, sodass zunächst nichts kaputt wirkt. Wenn es abläuft, scheitern alle Clients gleichzeitig, was wie ein Ausfall aussieht und nicht wie ein versäumter Deployment-Schritt. Die präsentierte Identität nach jeder Erneuerung zu prüfen verwandelt diese Überraschung in eine Routinebeobachtung.

Wählen Sie die Challenge, die zum Listener passt

Das Zertifikat muss den Host benennen, den Clients prüfen, verwenden Sie also den öffentlichen DNS-Namen statt eines internen Labels oder einer Adresse. HTTP-01 verlangt, dass die Challenge für einen Moment auf Port 80 beantwortet wird, was ein temporärer Listener ist und nie ein Grund, SoftEthers eigenen Port zu verschieben. DNS-01 weist Kontrolle über einen Record nach und braucht überhaupt kein eingehendes HTTP.

Unbeaufsichtigte Erneuerung bedeutet eine automatisierte DNS-Integration mit auf die eine Zone beschränkten Zugangsdaten, nicht einen TXT-Record, der alle paar Monate von Hand getippt wird. Ein Wildcard ändert den Challenge-Typ, nicht die Notwendigkeit dieser Automatisierung. Entscheiden Sie das, bevor das erste Zertifikat existiert, denn ein späterer Wechsel des Challenge-Typs bedeutet, Client-Konfiguration und Firewall gemeinsam anzufassen.

Halten Sie die Artefakte beisammen, solange Sie hier sind. Das Blattzertifikat und die Zwischenzertifikate kommen als getrennte Dateien und als eine kombinierte Chain-Datei, der private Schlüssel ist wieder separat, und der Import braucht die Kette mit ihrem passenden Schlüssel statt eines öffentlichen Zertifikats allein.

Importieren Sie die Kette auf Serverebene

Sichern Sie die Serverkonfiguration und bestätigen Sie, dass Sie die Verwaltungsschnittstelle noch erreichen, bevor Sie das Zertifikat anfassen. Verbinden Sie sich als Serveradministrator und nicht als Virtual-Hub-Administrator, denn das Zertifikat gehört zum Serverobjekt. Laden Sie dann Kette und Schlüssel per absolutem Pfad aus Dateien, die das ausführende Konto lesen kann. Beachten Sie, dass die Pfade absolut sind, weil der Befehl sie vom Arbeitsverzeichnis des Prozesses aus auflöst, der vpncmd gestartet hat:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

Lesen Sie die Befehlsausgabe, statt Erfolg anzunehmen, und lesen Sie dann die Kette zurück, statt der übergebenen Datei zu vertrauen. Die Grenze zwischen Builds, die ein ganzes PEM-Bundle importieren, und Builds, die nur das erste Zertifikat nehmen, ist nicht an einer Stelle dokumentiert, daher entscheidet die Prüfung für den Build vor Ihnen. Zählen Sie die Zertifikate, die der Listener präsentiert; ein Blatt ohne Zwischenzertifikate ist die Signatur eines Importeurs, der nur den ersten Block verbraucht hat.

Halten Sie den importierten Schlüssel nur für das Konto lesbar, das den Server ausführt, und halten Sie das Verwaltungskennwort aus der Shell-Historie heraus. Tippen Sie bei diesem ersten Import das Kennwort an der Eingabeaufforderung ein, statt es als Befehlsargument zu übergeben. Diese zwei Gewohnheiten kosten nichts und beseitigen den häufigsten Weg, auf dem ein Zertifikats-Deployment etwas preisgibt, das es schützen sollte. Tun Sie das vor dem ersten Import, nicht danach.

Hängen Sie das Deployment ein, nicht die Erneuerung

Sobald der manuelle Import funktioniert, packen Sie genau diese Schritte in einen kleinen Wrapper und rufen ihn nach einer erfolgreichen Erneuerung aus dem ACME-Client auf. Certbot setzt für den Hook RENEWED_LINEAGE und RENEWED_DOMAINS, sodass der Wrapper auf einem Rechner, der mehrere Zertifikate verwaltet, auf ein Zertifikat wirken kann. Filtern Sie nach der Lineage, statt auf jede Erneuerung auf dem Host zu reagieren. Der Wrapper ist Deployment-Code, der mit den Rechten des Servers läuft, daher prüfen Sie ihn wie jedes andere Skript in dieser Position.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

Ein Hook, der unbeaufsichtigt läuft, braucht einen eigenen geschützten Speicher für Zugangsdaten und ein Fehlersignal, das einen Menschen erreicht. Wenn die Ausstellung gelingt und der Import scheitert, wiederholen Sie den Import, statt ein weiteres Zertifikat anzufragen, denn eine zweite Anfrage verbirgt den Deployment-Defekt hinter einer frischen Datei. Die Certbot-Dokumentation zur Erneuerung stellt klar, dass ein Lauf, der nichts aktualisiert, ein normales Ergebnis ist, daher ist der Hook das, was beides unterscheidet.

Vergleichen Sie die präsentierte Kette mit der Datei

Lesen Sie den Listener, nicht die Platte. Verbinden Sie sich mit dem Servernamen, den die Clients verwenden, auf den clientseitigen Port und vergleichen Sie dann den Fingerabdruck und die gelieferte Kette mit der Lineage, die der Hook installiert hat. Zwei Befehle decken das ab, und der erste zeigt auch, ob Zwischenzertifikate überhaupt ankommen:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

Stellen Sie dann eine neue Clientverbindung her, denn Sitzungen, die vor dem Import aufgebaut wurden, wurden gegen die vorherige Identität authentifiziert und beweisen nichts über die neue. Wenn Clients das alte Blatt pinnen, brauchen sie eine koordinierte Aktualisierung, selbst wenn die öffentliche Kette gültig ist, und diese Aufgabe gehört in dasselbe Runbook wie die Erneuerung. Ein Reverse-Proxy vor dem Dienst kann ein gutes Zertifikat präsentieren, während der VPN-Listener noch das alte hält, weshalb die Prüfung den Port benennen muss, den Clients tatsächlich erreichen. Notieren Sie den Fingerabdruck neben dem Erneuerungsdatum, damit der nächste Vergleich eine Prüfung ist und kein Akt des Gedächtnisses.