TLS Zertifikat erneuern: ACME Weg und echte Abnahme

Erneuerung ist ein Betriebsprozess

Ein Zertifikat schützt eine Verbindung nur dann wie vorgesehen, wenn der Client den Namen und die Vertrauenskette prüfen kann. Für Betreiber reicht es deshalb nicht, dass in Plesk ein neues Zertifikat gespeichert ist. Der richtige virtuelle Host muss es ausliefern, alle benötigten Namen müssen enthalten sein und jeder veröffentlichte Weg muss funktionieren. Außerdem braucht die Erneuerung einen wiederholbaren Ablauf. Ein manuell gelöstes Problem heute kann beim nächsten Versuch wieder auftreten. Notieren Sie daher den zuständigen ACME Client, dessen Challengeweg, die verwalteten Namen und die Person, die Fehler bemerkt. Diese Grundlage ist wichtiger als die Erinnerung an einen einzelnen erfolgreichen Klick.

Beginnen Sie mit einer Liste der Hostnamen. Hauptdomain, www und ein zusätzliches Portal sind getrennte Namen, auch wenn sie dieselbe Website erreichen. Eine HTTPS Weiterleitung hilft erst nach dem TLS Verbindungsaufbau. Deshalb braucht bereits der Ausgangsname ein passendes Zertifikat. Prüfen Sie außerdem, ob weitere Dienste wie Mail oder ein Panel ein eigenes Zertifikat verwenden. Eine Websiteerneuerung darf nicht ungeprüft deren Zuordnung verändern. Der Umfang des Auftrags bleibt bewusst eng. Bei gemeinsam genutzten Servern ist besonders wichtig, dass ein neues Zertifikat nicht versehentlich als Standard für fremde Websites gesetzt wird oder eine bestehende Zuordnung ersetzt.

Die Challenge muss zum Schutzkonzept passen

Die Let’s Encrypt Dokumentation zu Challenges beschreibt verschiedene Wege zum Nachweis der Kontrolle. Bei HTTP wird eine vorgegebene Ressource über den Webweg bereitgestellt; bei DNS erfolgt der Nachweis mit einem passenden TXT Eintrag. Welcher Weg geeignet ist, hängt von der Umgebung und dem gewünschten Zertifikat ab. Für Wildcardnamen wird bei Let’s Encrypt DNS Validierung benötigt. Ein geschützter Entwurf kann einen gezielt eingerichteten Challengeweg oder DNS Validierung verwenden. Öffnen Sie für die Ausstellung nicht pauschal die gesamte Website. Der gewählte Weg soll die nötige Prüfung ermöglichen und die übrige Schutzgrenze erhalten.

Prüfen Sie die Zuständigkeit für DNS, wenn DNS Validierung eingesetzt wird. Eine lokale Zone auf dem Webserver muss nicht die öffentlich zuständige Zone sein. Bei einem externen DNS Dienst braucht der ACME Client den passenden sicheren Integrationsweg oder einen bewusst manuellen Prozess. Ein einmal von Hand gesetzter TXT Eintrag ist keine vollständige automatische Erneuerung. Dokumentieren Sie diese Grenze klar. Falls ein API Zugang genutzt wird, begrenzen Sie seine Rechte auf den nötigen Bereich und bewahren Sie ihn außerhalb öffentlicher Dateien auf. Ein Zugang in einem Skriptarchive oder einem veröffentlichten Fehlerbericht wäre ein unnötiger Verlust der gewünschten Schutzwirkung.

DNS vor dem neuen Versuch prüfen

Bevor Sie eine gescheiterte Ausstellung wiederholen, prüfen Sie die öffentliche Auflösung der betroffenen Namen. Fragen Sie A und AAAA bei den zuständigen Nameservern ab. Jeder veröffentlichte Webpfad muss die erforderliche Challenge korrekt beantworten können. Die Let’s Encrypt Beschreibung der IPv6 Validierung erläutert, warum eine falsche AAAA Adresse zu Fehlern führt: Die Validierung bevorzugt zunächst IPv6, und eine falsche Antwort ist etwas anderes als ein Netztimeout. Verlassen Sie sich deshalb nicht auf die Annahme, dass ein funktionierender IPv4 Pfad den zweiten Pfad automatisch ersetzt. Prüfen Sie beide bewusst und korrigieren Sie die tatsächliche Fehlkonfiguration.

Ein fehlender AAAA Eintrag und ein falscher AAAA Eintrag sind unterschiedliche Zustände. Wenn IPv6 vorgesehen ist, wird der passende Dienst zuerst eingerichtet und geprüft, danach die richtige Adresse veröffentlicht. Entfernen Sie den Eintrag nicht nur, um eine Fehlermeldung zu verdecken, ohne den gewünschten Betriebszustand zu klären. Wenn IPv6 für diese Domain nicht betrieben werden soll, muss die Veröffentlichung zu diesem Ziel passen. Der Ratgeber zur A und AAAA Prüfung zeigt die getrennten Belege. Halten Sie außerdem fest, ob der lokale Resolver noch alte Werte liefert. Der Client und die Zertifizierungsstelle können sonst unterschiedliche Wege sehen.

Challengefehler zielgerichtet eingrenzen

Lesen Sie bei einem Fehler den betroffenen Namen und die konkrete Antwort. War der Nachweis nicht erreichbar, kam eine Sperrseite zurück oder wurde der falsche Inhalt geliefert? Bei HTTP Validierung sind Weiterleitung, Zugriffsschutz, Proxy und Cache mögliche Stationen. Ein korrekt vorhandener Token im Dateisystem beweist noch nicht, dass die Zertifizierungsstelle ihn über den öffentlichen Weg erhält. Testen Sie denselben Namen von außen. Achten Sie bei mehreren Servern darauf, dass alle öffentlich verwendeten Ziele den richtigen Nachweis liefern. Eine zufällig richtige Antwort von einem Ziel kann einen zweiten falschen Weg verdecken und die Ausstellung scheinbar unregelmäßig scheitern lassen.

Bei DNS Validierung wird der tatsächlich veröffentlichte TXT Wert geprüft, nicht nur die Oberfläche. Eine automatische Integration kann an falschen Rechten, einer abweichenden Zone oder einem zu kurzen Warten auf den neuen Stand scheitern. Halten Sie im Bericht fest, welche Zone zuständig ist und welcher Schritt fehlgeschlagen ist. Geben Sie keine API Schlüssel oder vollständigen geheimen Konfigurationen weiter. Für eine erste Supportprüfung reichen Name, Zeitraum, Fehlerklasse und die relevante öffentliche Antwort. Ein manueller Erfolg nach einer Korrektur ist zunächst eine wieder funktionierende Ausstellung. Die automatische Wiederholung muss anschließend separat belegt werden, damit beim nächsten Ablauf kein versteckter manueller Handgriff nötig bleibt.

Wiederholungen nicht blind ausführen

Viele schnelle Ausstellungsversuche können den Fehler verschärfen, weil die Zertifizierungsstelle Grenzen für Anfragen und fehlgeschlagene Prüfungen besitzt. Die offiziellen Rate Limits gehören deshalb zur Diagnose. Lesen Sie die konkrete Fehlermeldung und den angegebenen nächsten Versuchstermin. Ändern Sie nicht fortlaufend die Namensliste, um ein Limit zu umgehen. Beseitigen Sie zuerst die Ursache und nutzen Sie für Entwicklung oder umfangreiche Tests die dafür vorgesehene Testumgebung. Eine solche Umgebung liefert keine produktiv vertrauenswürdige Abnahme, hilft aber, den Ablauf zu prüfen, ohne viele echte Ausstellungen für dieselben Namen anzufordern.

Auch das Löschen und Neuaufsetzen eines Clients auf Verdacht ist riskant. Dabei können Informationen zum bestehenden Konto und zur Erneuerung verloren gehen. Sichern Sie vor größeren Eingriffen die erforderlichen Konfigurationsdaten geschützt und verstehen Sie den bisherigen Ablauf. Private Schlüssel gehören nicht in ein öffentliches Projektpaket. Prüfen Sie, ob eine vorhandene funktionierende Erneuerung nur durch eine geänderte DNS Adresse oder eine neue Schutzregel gestört wurde. In diesem Fall ist die gezielte Korrektur meist leichter nachvollziehbar als ein vollständiger Neubeginn. Notieren Sie den früheren Zustand, den Auslöser und die neue Prüfung. So bleibt die Ursache auch später verständlich.

Ausstellung und Auslieferung separat abnehmen

Nach erfolgreicher Ausstellung kontrollieren Sie die Zuordnung im Hosting. Die Plesk Dokumentation zu TLS Zertifikaten erklärt deren Verwaltung. Im praktischen Test wird jede benötigte HTTPS Adresse ohne ausgeschaltete Zertifikatsprüfung aufgerufen. Prüfen Sie Namen, Gültigkeitszeitraum und den tatsächlich ausgelieferten Stand. Ein neues Zertifikat im Speicher kann ungenutzt bleiben, wenn eine andere Auswahl am Host aktiv ist. Bei einem vorgelagerten Dienst kann zudem dessen Zertifikat maßgeblich sein. Der Bericht muss daher nennen, ob Ursprung, äußerer Dienst oder regulärer Besucherweg geprüft wurde.

Testen Sie IPv4 und natives IPv6 getrennt, sofern beide veröffentlicht sind. Ein erfolgreicher normaler Browseraufruf kann den einen fehlerhaften Weg umgehen. Für die Abnahme interessiert jeder angebotene Pfad. Kontrollieren Sie danach die Weiterleitung von HTTP und von www auf die Hauptadresse. Verwenden Sie einen tiefen Pfad mit einem harmlosen Parameter, damit dessen Erhalt sichtbar wird. Das Ergebnis besteht aus mehreren Belegen: TLS passt zum Ausgangsnamen, das Ziel ist korrekt und der Inhalt stammt von der erwarteten Website. Eine beliebige Standardseite mit Status 200 erfüllt diese Anforderungen nicht. Der Anfrageweg durch die Webserver hilft bei einer falschen Hostzuordnung.

Gemischte Inhalte nach dem Wechsel prüfen

Nach einer Änderung der Hauptadresse können im Inhalt noch absolute HTTP Verweise stehen. Prüfen Sie wichtige Seitentypen im Browser und betrachten Sie relevante Meldungen in den Entwicklerwerkzeugen. Bilder, Skripte, Stile und eingebettete Dienste brauchen passende sichere Wege. Ändern Sie Datenbankinhalte nicht mit einem ungezielten Textersatz, wenn die Anwendung strukturierte oder serialisierte Werte verwendet. Nutzen Sie den vorgesehenen sicheren Weg und sichern Sie den Datenstand vorher. Für externe Dienste gilt: Eine eigene HTTPS Adresse macht deren unsichere Einbindung nicht automatisch sicher. Prüfen Sie, ob ein korrektes Ziel angeboten wird und ob die Funktion danach weiterhin wie erwartet arbeitet.

Eine Weiterleitung am Server repariert zudem nicht jede Anwendungseinstellung. Die Website kann weiterhin falsche absolute URLs erzeugen oder beim Login eine unpassende Adresse verwenden. Testen Sie daher Anmeldung, Medien, Formulare und Schnittstellen. Bei WordPress ist auch der geplante Jobweg relevant, wenn er über HTTP ausgelöst wird. Ein früher funktionierender Aufruf kann nach einer neuen Schutzregel oder Adresse scheitern. Unser Ratgeber zum Cron Betrieb behandelt diese Abhängigkeit. Die TLS Änderung wird damit als vollständiger Betriebswechsel geprüft und nicht nur als einmalige Kontrolle der Browseranzeige auf der Startseite.

Die nächste Erneuerung muss sichtbar bleiben

Eine funktionierende automatische Aufgabe sollte einen beobachtbaren Abschluss haben. Prüfen Sie ihren tatsächlichen Zeitplan, ausführenden Benutzer und die Logquelle. Ein erfolgreicher manueller Test ersetzt diese Angaben nicht. Für die Überwachung ist zusätzlich der von außen sichtbare Gültigkeitszeitraum sinnvoll. Er erkennt auch den Fall, dass ein neues Zertifikat zwar ausgestellt, aber nicht ausgeliefert wurde. Legen Sie einen Alarm mit ausreichendem Handlungszeitraum fest. Der passende Vorlauf richtet sich nach dem Erneuerungsprozess und der eigenen Reaktionszeit. Nennen Sie im Betriebskonzept die zuständige Person und den Eskalationsweg. Ein Warnwert ohne Empfänger schafft keine verlässliche Erneuerung.

Prüfen Sie den Alarm selbst mit einem kontrollierten Test. Eine Meldung kann im falschen Postfach landen oder während einer Wartung stumm geschaltet bleiben. Überwachung muss vom Messpunkt bis zur Reaktion funktionieren. Bei mehreren Zertifikaten sollten die Namen klar in der Meldung stehen, damit nicht die falsche Domain bearbeitet wird. Ein gemeinsames Zertifikat für viele Namen hat außerdem einen anderen Umfang als getrennte Zertifikate. Halten Sie fest, welche Namen zusammen erneuert werden und welche anderen Dienste davon abhängen. Der Ratgeber zur Alarmierung hilft, Schwelle, Empfänger und nächsten Handlungsschritt in einer brauchbaren Regel zu verbinden.

Eine sichere Übergabe nennt den geprüften Umfang

Die Abschlussnotiz enthält benötigte Namen, Challengeweg, Aussteller, sichtbaren Gültigkeitszeitraum, Zuordnung und die getesteten Adressfamilien. Ergänzen Sie den nächsten automatischen Lauf und die beobachtbare Fehlerquelle. Private Schlüssel und Zugangsdaten werden darin nur über sichere interne Referenzen beschrieben. Offene Grenzen bekommen einen konkreten nächsten Schritt, etwa eine noch nicht mögliche native IPv6 Prüfung am eigenen Standort. Ein solcher Bericht ist genauer als die pauschale Aussage SSL ist fertig. Er zeigt, welche Teile funktionieren und welche Abhängigkeit beim nächsten Wechsel erneut betrachtet werden muss. So kann ein anderes Teammitglied den Ablauf wiederholen, ohne sich auf unausgesprochene Erinnerungen zu verlassen.

Eine erfolgreiche TLS Erneuerung endet mit korrekter öffentlicher Auslieferung und einem überwachten Wiederholungsweg. Diese beiden Ziele bleiben auch dann getrennt, wenn eine Oberfläche sie in einem Assistenten bündelt. Bei einem Fehler folgt die Diagnose dem Weg von DNS über Challenge und Ausstellung bis zum richtigen Host. Damit werden unnötige neue Anträge, globale Änderungen und falsche Erfolgsaussagen vermieden. Der konkrete Nutzen ist ein bekannter Zustand, der nicht erst kurz vor Ablauf erneut entdeckt werden muss. Für Besucher zählt am Ende der passende sichere Weg zu ihrer Adresse; für Betreiber zählt zusätzlich, dass dieser Zustand ohne improvisierte manuelle Eingriffe erhalten bleibt.