Inventarisieren Sie Hostnamen, Abhängigkeiten und Zuständigkeiten
Listen Sie jeden Hostnamen auf, den Besucher oder Integrationen verwenden: Apex, www, Subdomains, APIs, Asset-Hosts, Portale und regionale Namen. Notieren Sie für jeden, wo TLS terminiert, wer es ändern kann, welche Zertifikatsabdeckung und welches Ablaufdatum bestehen, welche Erneuerungsmethode genutzt wird und welche Abhängigkeiten URLs erzeugen. Ein Zertifikat muss den angeforderten Hostnamen in seiner Subject Alternative Name-Liste abdecken. Beziehen Sie CMS, CDN, Tag-Manager, Objektspeicher, Zahlungsanbieter, E-Mail-Vorlagen und Drittanbieter-Einbettungen ein; diese verursachen nach der ersten HTTPS-Freigabe häufig HTTP-URLs.
Bestimmen Sie einen kanonischen www- oder Apex-Hostname und leiten Sie die Alternative direkt per HTTPS darauf um.
Zertifikat und aktuelle TLS-Versionen bereitstellen
Konfigurieren Sie den Webserver, Reverse-Proxy, das CDN oder den Load-Balancer, der die öffentlichen Anfragen beantwortet. Installieren Sie das Zertifikat und die erforderliche Kette, binden Sie sie an die vorgesehenen Namen und verifizieren Sie sie von außerhalb des Hosting-Netzwerks. Der Browser prüft Kette, Hostname und Gültigkeitszeitraum; eine öffentliche Warnung ist ein Release-Blocker. Standardisieren Sie auf TLS 1.3 und behalten Sie TLS 1.2 nur dort bei, wo die Kompatibilität es erfordert. Deaktivieren Sie SSL sowie TLS 1.0 und 1.1. Verwenden Sie die gepflegten Plattformempfehlungen statt einer kopierten veralteten Cipher-Liste und halten Sie Server und TLS-Bibliothek gepatcht.
Begrenzen Sie den Zugriff auf private Schlüssel und dokumentieren Sie jedes System, das einen Schlüssel teilt, damit ein Austausch alle Ziele erreicht.
HTTP direkt auf HTTPS umleiten und HTTPS kanonisch machen
Geben Sie eine serverseitige permanente Weiterleitung zurück, normalerweise 301 oder 308, von jeder HTTP-URL auf die äquivalente HTTPS-URL. Vermeiden Sie Ketten: Sie erhöhen Verzögerung und Fehlerquellen. Veröffentlichen Sie kanonische HTTPS-URLs in internen Links, canonical-Tags, Sitemaps, strukturierten Daten, Social-Tags, E-Mails und von Anwendungen generierten absoluten Links. Testen Sie die Startseite, eine tiefe Seite, eine Query-URL, Fehlerpfade und Hostvarianten. Wenn TLS an einem Proxy endet, konfigurieren Sie die vertrauenswürdige Behandlung des weitergeleiteten Protokolls, damit die Anwendung nicht zwischen HTTP und HTTPS hin- und herspringt.
HTTP darf nur noch zur Weiterleitung oder zur Vervollständigung einer Zertifikatschallenge verfügbar sein, nicht um eine separate öffentliche Site zu bedienen.
Gemischte Inhalte (Mixed Content) an der Quelle finden und beheben
Gemischte Inhalte entstehen, wenn eine HTTPS-Seite eine Ressource über HTTP oder ein anderes unsicheres Protokoll anfordert. Browser können einige Medien automatisch auf HTTPS umstellen, blockieren aber viele riskante Anfragen, darunter Skripte, Stylesheets, Frames, Fetch-Aufrufe und Schriftarten. Ersetzen Sie jede Referenz durch eine getestete HTTPS-URL, eine relative URL für eigene Inhalte oder eine genehmigte Alternative. Crawlen Sie repräsentative Templates und prüfen Sie die Entwicklertools, während Sie wichtige Nutzerpfade durchlaufen. Überprüfen Sie CSS, JavaScript, CMS-Blöcke, Asset-Manifeste, Tag-Manager-Einträge, Downloads und Anbieter-Einbettungen. Eine sichere Seite darf keinen HTTP-Download anbieten.
Die automatische Umstellung des Browsers auf HTTPS kann dennoch eine nicht verfügbare oder nicht unterstützte Drittabhängigkeit hinterlassen; korrigieren Sie die gespeicherte URL.
Erneuerung automatisieren und Zertifikatswiederherstellung proben
Behandeln Sie die Erneuerung als automatisierten Bereitstellungsprozess, nicht als Kalendererinnerung. Er muss das Zertifikat erneuern, auf jeder Auslieferungsebene bereitstellen und den Dienst sicher neu laden. Testen Sie denselben Validierungspfad vor dem Ablauf des Produktionszertifikats. Let’s Encrypt empfiehlt beispielsweise, seine 90-Tage-Zertifikate alle 60 Tage zu erneuern; folgen Sie dem Lebenszyklus Ihres Ausstellers und Ihrer Plattform. Führen Sie Zertifikatsnamen, Ausstellerkonto, Challenge-Methode, Automatisierung, Schlüsselort, Zielsysteme und Notfallkontakte in einem Inventar. Prüfen Sie die Gültigkeitsdaten nach dem Deployment vom öffentlichen Endpunkt aus.
Bei fehlgeschlagener Erneuerung prüfen Sie DNS, Challenge-Routing, Berechtigungen, Ausstellerzugang, Rate-Limits und CDN-zu-Origin-Deployment.
HSTS nur, wenn die HTTPS-Landschaft bereit ist
HTTP Strict Transport Security (HSTS) ist ein HTTPS-Antwort-Header, der Browser anweist, bei späteren Besuchen HTTPS für einen Host zu verwenden. Browser bieten dann keine Umgehung bei Zertifikatfehlern mehr an. Senden Sie HSTS nur über HTTPS und behalten Sie die HTTP-Weiterleitung, weil HSTS erst nach einer sicheren Antwort gelernt wird, sofern nicht eine Preload-Liste greift. Beginnen Sie mit einer begrenzten max-age und verlängern Sie sie erst, nachdem Sie Erneuerungen und erforderliche Pfade erfolgreich geprüft haben. Fügen Sie includeSubDomains erst hinzu, wenn jede gegenwärtige und zukünftige Subdomain gültiges HTTPS bereitstellen kann. Preload ist kein Teil der HSTS-Spezifikation und erfordert eine separate, langfristige Verpflichtungsprüfung.
max-age=0 wirkt nur, nachdem ein Browser eine gültige HTTPS-Antwort erreicht hat; es kann einen nicht erreichbaren sicheren Host nicht reparieren.
Freigeben, testen und zurückrollen, ohne den Transport zu schwächen
Sichern Sie vor Änderungen die bekanntermaßen funktionierende Zertifikats-, Edge- und Redirect-Konfiguration. Definieren Sie, wer ein Rollback genehmigt, nutzen Sie Staging, wo möglich, und ändern Sie jeweils nur eine Kontrollklasse. Prüfen Sie sofort öffentliche Endpunkte aus mehr als einem Netzwerk, folgen Sie Weiterleitungen, inspizieren Sie das Zertifikat und führen Sie wichtige Besucheraktionen aus. Testen Sie Browser und Client-Gruppen, die für Ihr Publikum relevant sind. Bei Zahlungs- oder regulierten Flows lassen Sie den Zahlungsanbieter und einen qualifizierten Sicherheitsexperten die Anforderungen überprüfen. Wenn eine Änderung HTTPS bricht, stellen Sie eine validierte sichere Konfiguration wieder her; machen Sie keine Kundenseiten per HTTP öffentlich als Workaround.
Erfassen Sie Hostname, Zeit, Client, Fehler, Änderung und Ergebnis, damit die nächste Erneuerung oder Migration leichter zu diagnostizieren ist.