Ein Hostingpaket mit Zertifikatfunktion kann die HTTPS-Einrichtung erleichtern. Die Website muss dennoch mit dem richtigen Namen erreichbar sein, ein gültiges passendes Zertifikat ausliefern und ihre Inhalte vollständig über sichere Verbindungen laden. Dazu kommt die Erneuerung im laufenden Betrieb. Dieser Ratgeber verbindet diese Punkte zu einer Abnahme, die Sie für eine neue Website oder einen Hostingwechsel verwenden können.

Was die sichere Verbindung tatsächlich umfasst

Im Hostingalltag wird häufig von SSL gesprochen, obwohl heutige sichere Webverbindungen TLS verwenden. Das Zertifikat gehört zur Prüfung der angesprochenen Identität und ermöglicht zusammen mit dem Protokoll die geschützte Verbindung. Es ersetzt weder Anwendungssicherheit noch korrekte Zugriffsrechte. Eine Website mit gültigem HTTPS kann weiterhin fehlerhaften Code, irreführende Inhalte oder ungeschützte Verwaltungsfunktionen enthalten. Bewerten Sie die Verbindung deshalb als einen notwendigen Bestandteil des Betriebs.

Beginnen Sie mit der geplanten Hauptadresse. Soll die Website unter der Hauptdomain oder unter www verwendet werden? Welche Subdomains haben eigene Dienste? Schreiben Sie diese Namen auf und prüfen Sie ihre Behandlung. Ein Zertifikat für einen einzelnen Namen deckt nicht automatisch jede andere Variante ab. Ebenso muss der richtige virtuelle Host auf dem Server antworten. Eine verschlüsselte Verbindung zu einer Standardseite ist noch keine erfolgreiche Einrichtung Ihrer Website.

DNS und Hostingzuordnung vor der Ausstellung prüfen

Die Domain muss zum vorgesehenen System führen oder über ein geeignetes Verfahren verifiziert werden. Prüfen Sie den DNS-Bestand für IPv4 und IPv6 sowie die tatsächliche Domainzuordnung im Hosting. Wenn verschiedene Wege zu unterschiedlichen Servern führen, können auch Ausstellung oder Erneuerung unerwartet scheitern. Der Ratgeber Domain und DNS beim Umzug erläutert die getrennte Kontrolle von autoritativen Antworten und realen Verbindungen.

Für automatisierte Zertifikate beschreibt Let’s Encrypt verschiedene ACME-Challenges. HTTP-01 prüft einen bereitgestellten Wert über HTTP auf Port 80. DNS-01 prüft einen DNS-TXT-Wert und ermöglicht unter anderem Wildcard-Zertifikate. Welche Methode im konkreten Hostingpanel angeboten und automatisiert wird, muss am tatsächlichen Paket geprüft werden. Eine theoretisch geeignete Methode ist noch keine konfigurierte Erneuerung.

Prüfebenen einer HTTPS-Einrichtung
Ebene Prüfgegenstand Erfolg bedeutet
Domain Benötigte Haupt- und Zusatznamen Alle genutzten Namen haben eine klare Behandlung
DNS A, AAAA und Verifikationsweg Die vorgesehenen Systeme sind erreichbar
Zertifikat Namensabdeckung, Gültigkeit und Vertrauenskette Normale Clients akzeptieren den richtigen Namen
Website Weiterleitungen und Ressourcen Inhalt und Funktionen laden sicher
Betrieb Erneuerung und Fehlermeldung Ein verantwortlicher Prozess bleibt aktiv

Den tatsächlichen Domainaufruf abnehmen

Rufen Sie jede vorgesehene HTTPS-Variante mit normaler Namensprüfung auf. Achten Sie auf das ausgelieferte Zertifikat, seine Namen und den gewünschten Inhalt. Deaktivieren Sie die Zertifikatsprüfung für diese Abnahme nicht. Ein Werkzeug kann bei abgeschalteter Prüfung durchaus eine Antwort liefern, obwohl normale Besucher eine Warnung sehen. Das ist ein diagnostischer Zugriff mit begrenzter Aussagekraft, kein Beleg für korrektes öffentliches HTTPS.

Prüfen Sie IPv4 und natives IPv6 jeweils gesondert, soweit beide veröffentlicht werden. Ein erfolgreicher Aufruf über eine Adressfamilie bestätigt die andere nicht. Nach einem Hostingwechsel kann ein alter AAAA-Eintrag einen anderen Server mit einem anderen Zertifikat erreichen. Die offiziellen Hinweise von Let’s Encrypt zu IPv6 zeigen zudem, warum IPv6 auch beim Verifikationsweg relevant sein kann. Dokumentieren Sie vorhandene Testgrenzen, statt sie als bestandene Prüfung zu behandeln.

Weiterleitungen ohne Sackgassen einrichten

Legen Sie eine klare Hauptadresse fest und führen Sie gewünschte Varianten dorthin. Prüfen Sie HTTP, HTTPS und www jeweils mit einem existierenden Unterpfad. Eine Weiterleitung sollte den benötigten Pfad und relevante Parameter erhalten. Wenn aus jeder Adresse nur die Startseite wird, können alte Verweise, Kampagnen und direkte Downloads unbrauchbar werden. Testen Sie dafür mehrere harmlose Beispiele, die in Ihrem eigenen Bestand tatsächlich vorkommen.

Denken Sie an die Reihenfolge der HTTPS-Verbindung. Der Browser prüft das Zertifikat, bevor eine HTTP-Weiterleitung aus der verschlüsselten Antwort ausgewertet wird. Ein falsches Zertifikat auf einer weiterleitenden Domainvariante bleibt daher ein Fehler. Prüfen Sie außerdem Schleifen zwischen Webserver, vorgeschaltetem Proxy und Anwendung. Eine WordPress-Einstellung und eine Panelregel können dasselbe Ziel unterschiedlich interpretieren. Eine dokumentierte zuständige Konfiguration macht spätere Änderungen übersichtlicher.

WordPress und gespeicherte Inhalte berücksichtigen

Die WordPress-Dokumentation zu HTTPS ist eine offizielle Grundlage für die Anwendungseinrichtung. Prüfen Sie die Websiteadressen und vorhandene absolute Links im tatsächlichen Bestand. Nach einer Umstellung können alte Bild- oder Skriptadressen weiterhin auf HTTP zeigen. Eine Korrektur der Hauptadresse allein beseitigt nicht zwangsläufig jeden gespeicherten Verweis. Gehen Sie mit einer gesicherten Kopie und einem geeigneten Verfahren vor.

Ersetzen Sie Datenbankinhalte nicht mit einem wahllosen Texteditorverfahren. Anwendungen können strukturierte oder serialisierte Werte verwenden, deren Darstellung beim Austausch erhalten bleiben muss. Prüfen Sie das gewählte Migrationswerkzeug und sichern Sie vorher den Bestand. Testen Sie anschließend repräsentative Seiten, Medien und Erweiterungen. Der Ratgeber Backup und Wiederherstellung beschreibt, wie eine brauchbare Rückfallgrundlage bewertet wird. Eine Sicherheitskopie gehört vor die Änderung, nicht erst hinter den auftretenden Fehler.

Mixed Content in den wirklichen Benutzerabläufen suchen

MDN erläutert Mixed Content als unsichere Ressourcen innerhalb sicher geladener Seiten. Browser können solche Zugriffe aufwerten oder blockieren; Sie sollten sich jedoch nicht auf automatische Korrektur verlassen. Prüfen Sie die Entwicklerkonsole und Netzwerkanfragen an repräsentativen Seiten. Ein fehlendes Skript kann beispielsweise eine Funktion betreffen, die auf der Startseite gar nicht vorhanden ist.

Nehmen Sie Formulare, Bilder, Schriftdateien, eingebettete Medien und Downloads in die Prüfung auf. Beachten Sie auch Inhalte aus einem externen Dienst. Für eine sichere URL muss die Gegenstelle HTTPS tatsächlich unterstützen; bloßes Austauschen des Protokolltextes reicht nicht, wenn dort keine passende Ressource bereitsteht. Entscheiden Sie bei einer nicht sicher verfügbaren Einbindung, ob sie ersetzt, lokal rechtmäßig bereitgestellt oder weggelassen werden kann. Halten Sie die Korrektur in der Inhalts- oder Betriebsdokumentation fest.

Erneuerung als laufende Aufgabe behandeln

Ein heute gültiges Zertifikat hat ein Ende seiner Gültigkeit. Entscheidend ist, ob das eingerichtete Verfahren später erneut erfolgreich arbeiten kann. Fragen Sie nach automatischer Erneuerung, ihrer Zuständigkeit und der Meldung bei Fehlern. Prüfen Sie am konkreten Hostingbestand, ob Aufgaben laufen und welche Protokolle verfügbar sind. Eine aktivierte Checkbox allein belegt keinen erfolgreich abgeschlossenen zukünftigen Prozess. Auch eine einmalige manuelle Ausstellung ist noch keine dauerhaft automatisierte Verwaltung.

Bewahren Sie die Voraussetzungen des Verifikationswegs. Ein späterer DNS-Wechsel, eine gesperrte Prüfadresse oder geänderte API-Berechtigungen können relevant sein. Dokumentieren Sie, welche Ausnahme für ACME nötig ist und wie sie eng begrenzt wird. Für einen geschützten Entwurf sollen nicht vorsorglich ganze Medienverzeichnisse öffentlich werden. Eine benötigte Verifikation kann gezielt behandelt werden. Nach wichtigen Änderungen wird die Erneuerungskonfiguration wieder geprüft.

Planen Sie eine unabhängige Kontrolle der Zertifikatsgültigkeit. Sie sollte die tatsächlich benutzte Domain prüfen und eine verantwortliche Person rechtzeitig erreichen. Ein internes Werkzeugstatusfeld kann eine andere Perspektive zeigen als eine externe Verbindung. Definieren Sie, wer Meldungen bearbeitet und wie die Vertretung funktioniert. Der Support- und Verantwortungsplan verhindert, dass ein Zertifikatsproblem zwischen Anbieter, Agentur und Betreiber liegen bleibt.

HSTS erst nach vollständiger Prüfung bewerten

HTTP Strict Transport Security teilt Browsern mit, die betreffenden Verbindungen künftig über HTTPS zu führen. Die MDN-Dokumentation zum HSTS-Header beschreibt auch die Erweiterung auf Subdomains. Diese Einstellung verlangt einen verlässlichen HTTPS-Bestand. Prüfen Sie alle betroffenen Namen und Dienste, bevor Sie eine weitreichende Richtlinie aktivieren. Die Vorgabe kann länger wirken als eine einzelne Serveränderung und gehört daher in die technische Planung.

Eine längere Richtlinie ist keine Abkürzung zur Reparatur fehlerhafter Zertifikate. Sie setzt voraus, dass die sichere Verbindung funktioniert. Behandeln Sie zusätzliche Subdomains und mögliche Preload-Entscheidungen als eigenständige Schritte mit ihren dokumentierten Bedingungen. Für einen kleinen Websitebetreiber kann die wichtigste erste Aufgabe sein, Hauptadresse, www, Inhalte und Erneuerung sauber zu betreiben. Lassen Sie weitergehende Richtlinien fachlich passend einrichten, ohne ungetestete Standardwerte aus fremden Projekten zu kopieren.

Beispiel und Abnahmeprotokoll

Bei einem Zertifikatsfehler lohnt eine präzise Fehlermeldung. Ein nicht passender Name, ein abgelaufener Stand und eine nicht akzeptierte Vertrauenskette weisen auf unterschiedliche Aufgaben hin. Schreiben Sie den betroffenen Hostnamen und den Zeitpunkt auf, bevor Sie Einstellungen verändern. Prüfen Sie, ob der Fehler in mehreren normalen Browsern und Netzen auftritt. Eine allgemeine Nachricht wie „SSL kaputt“ lässt offen, ob die Verbindung, die Anwendung oder nur eine einzelne externe Ressource betroffen ist.

Falls ein vorgeschalteter Dienst die HTTPS-Verbindung beendet, muss auch dieser Teil des Wegs betrachtet werden. Das Zertifikat am öffentlich angesprochenen Endpunkt kann sich vom Zertifikat der Ursprungsumgebung unterscheiden. Dokumentieren Sie, welcher Dienst für welche Verbindung zuständig ist, und ändern Sie nur den tatsächlich betroffenen Bereich. Eine erfolgreiche Prüfung des Ursprungsservers allein bestätigt die öffentliche Verbindung über einen vorgeschalteten Dienst nicht. Die Abnahme sollte deshalb den von Besuchern verwendeten normalen Weg einschließen.

Bewahren Sie private Schlüssel und Verwaltungszugänge geschützt auf. Screenshots für eine Übergabe sollten nur nicht vertrauliche Konfigurations- und Prüfinformationen zeigen. Wenn ein Supportkontakt zusätzliche Daten benötigt, nutzen Sie den dafür vorgesehenen sicheren Weg. Die Leserschaft braucht im Betriebsprotokoll Namen, Verantwortlichkeiten und Ergebnisse, aber keine geheimen Werte.

Eine neu eingerichtete Unternehmenswebsite soll die Hauptdomain verwenden. Das Team prüft zunächst, ob Hauptdomain und www am vorgesehenen Server ankommen. Beide HTTPS-Aufrufe werden mit Namensprüfung getestet; www führt auf die Hauptadresse. Danach folgen ein älterer Artikel, ein Formular und ein Download. Eine HTTP-Schriftdatei wird beim Funktionstest sichtbar und gezielt korrigiert. Erst nach dieser Korrektur gilt der betreffende Seitenablauf als erfolgreich geprüft.

Das Beispiel zeigt einen Arbeitsweg und behauptet keinen hier durchgeführten Kundentest. Im tatsächlichen Protokoll gehören zu jeder Prüfung Zeitpunkt, Hostname, Adressfamilie und Ergebnis. Eine rote Beobachtung bleibt erhalten, bis eine neue Prüfung die Behebung bestätigt. Notieren Sie außerdem die Erneuerungszuständigkeit und die vorgesehenen Meldungen. Damit wird HTTPS als wiederkehrende Betriebsaufgabe verständlich und kann beim nächsten Umzug kontrolliert übernommen werden.

  • Alle benötigten Namen sind im Zertifikats- und Weiterleitungsplan enthalten.
  • HTTPS funktioniert mit normaler Zertifikatsprüfung über die veröffentlichten Wege.
  • Pfade und Parameter bleiben bei Weiterleitungen erhalten.
  • Repräsentative Seiten und Funktionen sind frei von fehlerhaften unsicheren Einbindungen.
  • Erneuerung und Fehlermeldung haben eine geprüfte Konfiguration und klare Zuständigkeit.
  • Weitergehende Richtlinien passen zum gesamten betroffenen Domainbestand.

Für den Hostingvergleich fragen Sie nach den konkret verfügbaren Funktionen: Zertifikatsverwaltung, zusätzliche Domainnamen, Erneuerung und Unterstützung bei Fehlern. Belegte Funktionen helfen bei der Auswahl; eine allgemeine Werbeaussage zur Sicherheit beantwortet diese Betriebsfragen nicht. Ihre eigene Abnahme ergänzt die Produktinformationen und zeigt, ob die Website nach der Einrichtung unter den vorgesehenen Adressen wirklich nutzbar ist.