Halten Sie HTTPS über den gesamten Zertifikatslebenszyklus funktionsfähig
Ein Browser, der heute eine sichere Verbindung anzeigt, ist der Beginn des Zertifikatsbetriebs, nicht das Ende. Eine Domain kann umziehen, ein Validierungspfad kann sich ändern, oder eine Erneuerung kann erfolgreich sein, ohne dass der öffentliche Dienst das neue Zertifikat lädt. Behandeln Sie Ausstellung, Deployment und fortlaufende Verifizierung als getrennte Schritte mit einem klaren Verantwortlichen.
Das Wichtigste in Kürze
Kennen Sie jeden TLS-Terminierungspunkt, automatisieren Sie die Erneuerung mit der passenden Validierungsmethode, testen Sie diesen Prozess und prüfen Sie, ob das Zertifikat nach dem Deployment tatsächlich an die Nutzer ausgeliefert wird.
Erfassen, wo die sichere Verbindung endet
Listen Sie die Hostnamen auf, die Nutzer tatsächlich besuchen, einschließlich der Hauptdomain, eines etwaigen www-Namens, Anwendungs-Subdomains und wichtiger API-Endpunkte. Identifizieren Sie dann, wo TLS für jeden davon terminiert: ein Webserver, Reverse Proxy, Load Balancer oder ein anderer verwalteter Dienst. Ein auf dem Origin installiertes Zertifikat beweist nicht, dass ein separater öffentlicher Proxy dasselbe ausliefert. Bewahren Sie dieses Inventar bei den Personen auf, die für Domains und Hosting-Zugriff verantwortlich sind.
Ein Zertifikat muss den vom Client angeforderten Hostnamen abdecken und zu einem Vertrauensanker führen, den dieser Client akzeptiert. Der Dienst muss außerdem das relevante Zertifikat und die Zwischenkette korrekt präsentieren. Prüfen Sie mehr als eine bequeme URL, wenn Anwendungen mehrere Namen verwenden. Eine erfolgreiche Verbindung zur reinen Domain sagt wenig über eine API-Subdomain oder einen separaten Maildienst aus, die einen eigenen Zertifikatsprozess haben können.
HTTPS schützt die Verbindung unter dem geltenden Protokoll und der geltenden Konfiguration; es ist kein Beleg dafür, dass die Anwendung keine Schwachstellen hat oder ein Händler vertrauenswürdig ist. Behalten Sie Zugriffskontrolle, Updates und Backups in Ihrem eigenen Betriebsplan. Die Webhosting-Funktionsliste von HM Bastion umfasst die automatisierte SSL-Erneuerung, während ein VPS-Administrator die in seinem eigenen Stack verwendeten Zertifikatswerkzeuge bestätigen und verwalten muss. Gehen Sie nicht davon aus, dass diese Verantwortlichkeiten identisch sind.
Validierung passend zur betriebenen Umgebung wählen
ACME automatisiert die Interaktionen beim Bezug von Zertifikaten, einschließlich des Nachweises der Kontrolle über die angeforderten Domainnamen. Verschiedene Challenge-Methoden passen zu verschiedenen Umgebungen. Die Validierung über HTTP setzt voraus, dass der erforderliche Validierungspfad wie von der Zertifizierungsstelle vorgegeben erreichbar ist. Die Validierung über DNS setzt die Kontrolle über die relevanten DNS-Einträge voraus. Lesen Sie die Dokumentation der Zertifizierungsstelle und des Clients, bevor Sie eine Methode wählen, insbesondere wenn ein Proxy oder mehrere Anwendungsinstanzen vor dem Origin stehen.
| Betriebliche Frage | Was festzulegen ist |
|---|---|
| Wer kontrolliert DNS? | Ein benannter Verantwortlicher und der erforderliche Validierungszugriff |
| Wo können Validierungsanfragen eintreffen? | Das öffentliche Routing und die Challenge-Behandlung für jeden relevanten Namen |
| Wie werden Anmeldedaten gespeichert? | Private Speicherung und die engsten verfügbaren Berechtigungen |
| Was geschieht nach der Ausstellung? | Deployment auf den richtigen Dienst und ein verifizierter Reload |
Die Automatisierung von DNS kann Anmeldedaten mit erheblicher Macht über eine Domain erfordern. Speichern Sie diese außerhalb öffentlicher Verzeichnisse und geben Sie ihnen nur die Berechtigungen, die die gewählte Integration benötigt, sofern dies unterstützt wird. Trennen Sie die Dokumentation des Prozesses von den tatsächlichen geheimen Werten. Manuelle Validierung kann für eine bestimmte Einrichtung angemessen sein, erzeugt aber eine wiederkehrende menschliche Abhängigkeit; halten Sie schriftlich fest, wer sie durchführt und wie eine bevorstehende Erneuerung bemerkt wird.
Nutzen Sie die Staging-Umgebung der Zertifizierungsstelle beim Testen einer Integration, sofern verfügbar. Sie ermöglicht es, den Prozess zu durchlaufen, ohne wiederholte Ausstellungen in der Produktion als Debugging-Methode zu behandeln. Ein Staging-Zertifikat ist für den normalen öffentlichen Dienst nicht vertrauenswürdig, daher sollte der Zweck des Tests klar bleiben. Vermeiden Sie fest codierte Annahmen über Zertifikatslaufzeiten oder Erneuerungspläne, wenn die Zertifizierungsstelle und der Client Hinweise oder Erneuerungsinformationen bereitstellen, die sich ändern können.
Erneuerung, Deployment und Reload sind getrennte Ergebnisse
Prüfen Sie, ob der geplante Erneuerungsmechanismus tatsächlich unter dem vorgesehenen Konto und in der vorgesehenen Umgebung läuft. Ein Befehl, der in einem interaktiven Terminal funktioniert, kann auf einen Pfad, eine Berechtigung oder ein Anmeldedatum angewiesen sein, das bei der geplanten Ausführung fehlt. Prüfen Sie die relevanten Logs und verwenden Sie das vom Client unterstützte Verfahren zum Testen der Erneuerung. Für Certbot beschreibt die Dokumentation Dry-Run-Tests und Renewal-Hooks; folgen Sie den Anweisungen, die zur installierten Version und zum gewählten Authenticator passen.
Eine neu geschriebene Zertifikatsdatei ändert nicht automatisch, was ein laufender Dienst präsentiert. Der Dienst benötigt möglicherweise ein Neuladen, einen Deployment-Hook oder eine Verteilung an mehrere Terminierungspunkte. Validieren Sie die Konfiguration vor dem Neuladen, behalten Sie einen Rollback-Pfad bei und prüfen Sie anschließend die öffentliche Verbindung. In einem Multi-Node-Setup kann eine einzelne erfolgreiche Anfrage nur einen Node erreichen. Planen Sie eine Prüfung, die das tatsächliche Deployment abdeckt, statt anzunehmen, dass jede Instanz gemeinsam geändert wurde.
Überwachen Sie das extern bereitgestellte Zertifikat, die abgedeckten Namen und die verbleibende Zeit bis zum Ablauf. Damit erfassen Sie einen anderen Fehler als bei der Überwachung, ob der Erneuerungsjob erfolgreich zurückgekehrt ist. Halten Sie die Zuständigkeit für Benachrichtigungen aktuell, auch wenn eine Agentur oder ein Administrator wechselt. Eine an ein aufgegebenes Postfach gesendete Warnung bietet wenig Schutz. Überprüfen Sie das Inventar nach einer Änderung von DNS, dem Hinzufügen eines Reverse-Proxys, dem Verschieben eines Hostnamens oder einer Änderung der Konfiguration des Webservers.
Untersuchen Sie eine fehlgeschlagene Erneuerung ausgehend vom fehlgeschlagenen Schritt
- Erfassen Sie den betroffenen Hostnamen, die Client-Version, den Zeitpunkt und den genauen, nicht geheimen Fehler.
- Stellen Sie fest, ob der Fehler bei Validierung, Ausstellung, Deployment oder öffentlicher Bereitstellung liegt.
- Prüfen Sie das relevante DNS, das Routing, den Dateizugriff und die Umgebung des geplanten Jobs.
- Beheben und testen Sie die eng gefasste Ursache, bevor Sie die Produktionsausstellung erneut versuchen.
- Überprüfen Sie nach der Wiederherstellung das öffentliche Zertifikat und die normalen Anwendungsabläufe.
Wenn die Validierung beispielsweise nach einer Änderung von DNS fehlschlägt, vergleichen Sie die aktuellen öffentlichen Einträge mit der vorgesehenen Challenge-Route, bevor Sie die Zertifikats-Tools ersetzen. Wenn die Ausstellung erfolgreich ist, der Browser aber weiterhin ein altes Zertifikat sieht, prüfen Sie den öffentlichen Terminierungspunkt und den Deployment-Prozess. Wiederholte Zertifikatsanfragen beheben keinen Proxy, der eine andere Datei liest. Halten Sie den ursprünglichen Fehler und die nachfolgenden Maßnahmen in einer Zeitleiste fest, damit die nächste Person die Diagnose nachvollziehen kann.
Wenn ein privater Schlüssel offengelegt worden sein könnte, behandeln Sie dies als Sicherheitsvorfall und nicht als gewöhnliche Ablauf-Erinnerung. Die Reaktion kann das Ersetzen von Schlüsseln, das Widerrufen betroffener Zertifikate über den geeigneten Prozess und die Untersuchung der Offenlegung umfassen. Legen Sie niemals einen privaten Schlüssel oder DNS-Zugangsdaten in ein Support-Ticket. Teilen Sie den Hostnamen, gegebenenfalls Zertifikatskennungen und sichere Diagnoseausgaben, damit das Team untersuchen kann, ohne die Kontrolle über die Domain zu erhalten.
