Ein abgelaufenes SSL-Zertifikat ist für einen Online-Shop ein sofortiger Totalausfall -- moderne Browser blockieren die Verbindung mit einer Warnseite, die nahezu kein Besucher übergeht. Trotzdem gehören Zertifikatsablauf-Ausfälle zu den häufigsten vermeidbaren Downtime-Ursachen. 85 Prozent (Projekterfahrung) der befragten Unternehmen hatten in den letzten zwei Jahren mindestens einen Ausfall durch ein abgelaufenes Zertifikat (Ponemon Institute, 2025). Mit automatischer Erneuerung, proaktivem Monitoring und korrekter TLS-Konfiguration lassen sich diese Ausfälle vollständig vermeiden.
Let's Encrypt: Kostenlose Zertifikate automatisiert
Let's Encrypt hat die SSL-Landschaft revolutioniert: Kostenlose, automatisierte und vertrauenswürdige Zertifikate, die von allen gängigen Browsern und Betriebssystemen akzeptiert werden. Über 350 Millionen (Projekterfahrung) aktive Zertifikate (Let's Encrypt, 2026) machen den Dienst zur weltweit größten Zertifizierungsstelle. Für die meisten Online-Shops sind Let's-Encrypt-Zertifikate die richtige Wahl -- sie bieten die gleiche Verschlüsselungsstärke wie kostenpflichtige Zertifikate.
Die Automatisierung über Certbot oder alternative ACME-Clients stellt sicher, dass Zertifikate vor ihrem Ablauf automatisch erneuert werden. Die Gültigkeit eines Let's-Encrypt-Zertifikats beträgt 90 Tage -- bewusst kürzer als bei kommerziellen Zertifikaten, um häufigere Rotation und damit höhere Sicherheit zu erzwingen. Certbot erneuert standardmäßig 30 Tage vor Ablauf -- genug Puffer für mehrere Erneuerungsversuche, falls der erste fehlschlägt.
Für Shops mit mehreren Subdomains bieten sich Wildcard-Zertifikate an (*.example.de), die alle Subdomains mit einem einzigen Zertifikat abdecken. Die Validierung erfolgt über DNS-TXT-Records statt HTTP -- dies erfordert eine API-Anbindung an den DNS-Provider, die einmalig konfiguriert wird. Für Multi-Domain-Setups eignen sich SAN-Zertifikate (Subject Alternative Name), die mehrere verschiedene Domainnamen in einem Zertifikat bündeln. Beide Varianten lassen sich mit Let's Encrypt automatisiert verwalten.
Automatische Erneuerung
Certbot erneuert Zertifikate 30 Tage vor Ablauf automatisch. Cron-Jobs prüfen zweimal täglich und starten den Webserver bei Bedarf neu.
TLS 1.3 Konfiguration
Aktuelle TLS-Version mit starken Cipher-Suites. TLS 1.0 und 1.1 werden deaktiviert, da sie als unsicher gelten.
HSTS und Preloading
HTTP Strict Transport Security erzwingt HTTPS-Verbindungen. HSTS-Preloading schützt bereits beim allerersten Besuch.
Mixed-Content-Prüfung
Systematische Prüfung aller Seiten auf HTTP-Ressourcen. Bilder, Scripts und Fonts müssen vollständig über HTTPS laden.
Zertifikats-Monitoring
Tägliche Prüfung der Gültigkeit, Zertifikatskette und TLS-Konfiguration mit 30-Tage-Vorwarnung.
CAA-Records
DNS-basierte Autorisierung beschränkt, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen.
Zertifikatstypen: DV, OV, EV und Wildcard im Vergleich
Die Wahl des richtigen Zertifikatstyps hängt von den Anforderungen des Online-Shops ab. Domain-Validated-Zertifikate (DV) bestätigen lediglich die Domain-Inhaberschaft und werden in Sekunden ausgestellt -- sie sind für die meisten Shops ausreichend und bieten die gleiche Verschlüsselungsstärke wie teurere Varianten. Organization-Validated-Zertifikate (OV) prüfen zusätzlich die Unternehmensidentität, was ein höheres Vertrauenssignal darstellt, aber keinen sichtbaren Unterschied in modernen Browsern macht.
Extended-Validation-Zertifikate (EV) durchlaufen die umfassendste Prüfung, zeigen aber seit der Entfernung der grünen Adressleiste in Chrome und Firefox (2019) keinen visuellen Unterschied mehr für den Endnutzer. Für Multi-Domain-Setups sind SAN-Zertifikate (Subject Alternative Name) die wirtschaftlichste Lösung, da sie bis zu 100 verschiedene Domainnamen in einem einzigen Zertifikat bündeln. In einem typischen E-Commerce-Setup mit Hauptdomain, API-Subdomain und Staging-Umgebung reduziert ein SAN-Zertifikat den Verwaltungsaufwand erheblich.
TLS-Konfiguration: Mehr als nur das Zertifikat
Ein gültiges Zertifikat ist nur die Hälfte der SSL-Sicherheit. Die TLS-Konfiguration des Webservers bestimmt, welche Protokollversionen und Verschlüsselungsalgorithmen verwendet werden. Veraltete Protokolle wie TLS 1.0 und 1.1 enthalten bekannte Schwachstellen und werden von aktuellen Browsern nicht mehr unterstützt. Die empfohlene Konfiguration für 2026: TLS 1.2 als Minimum, TLS 1.3 als Standard.
TLS 1.3 bietet signifikante Vorteile: kürzerer Handshake (1 Round-Trip statt 2), stärkere Verschlüsselung durch Entfernung unsicherer Algorithmen und Forward Secrecy als Pflicht. Die Cipher-Suite-Konfiguration sollte nur AEAD-Cipher (Authenticated Encryption with Associated Data) wie AES-256-GCM und ChaCha20-Poly1305 zulassen. Schwache Cipher wie RC4, 3DES und CBC-Modus-Cipher sollten vollständig deaktiviert werden.
OCSP Stapling verbessert die Performance der TLS-Verbindung: Statt dass der Browser den Widerrufsstatus des Zertifikats separat bei der Zertifizierungsstelle abfragt, liefert der Server die OCSP-Antwort zusammen mit dem Zertifikat. Dies spart einen zusätzlichen Netzwerk-Roundtrip und beschleunigt den Verbindungsaufbau um 50 bis 100 Millisekunden. Die korrekte TLS-Konfiguration ist ein wichtiger Bestandteil der professionellen Serverwartung.
HSTS: HTTPS-Verbindungen erzwingen
Der HTTP Strict Transport Security (HSTS) Header instruiert den Browser, ausschließlich HTTPS-Verbindungen zur Website aufzubauen -- auch wenn der Nutzer http:// in die Adressleiste eingibt. Ohne HSTS ist der erste Verbindungsaufbau über HTTP anfällig für Man-in-the-Middle-Angriffe, die den Besucher auf eine gefälschte HTTP-Version der Website umleiten können (SSL-Stripping).
Die empfohlene HSTS-Konfiguration lautet: max-age=31536000 (1 Jahr), includeSubDomains (schützt auch alle Subdomains) und optional preload (Website wird in die Browser-Preload-Liste aufgenommen). Das Preloading bietet den stärksten Schutz, da HSTS bereits beim allerersten Besuch greift -- ohne dass der Browser vorher einen HSTS-Header empfangen haben muss. Die Aufnahme in die Preload-Liste erfordert die Erfüllung aller Kriterien auf hstspreload.org.
Vorsicht ist geboten bei der erstmaligen HSTS-Aktivierung: Ein fehlerhaft konfigurierter HSTS-Header kann dazu führen, dass die Website bei SSL-Problemen nicht mehr erreichbar ist -- der Browser verweigert jede HTTP-Verbindung. Deshalb empfehlen wir einen schrittweisen Rollout: zunächst mit kurzem max-age (z.B. 300 Sekunden), dann nach Verifizierung schrittweise auf den Zielwert erhöhen.
SSL-Labs-Test: A+-Rating erreichen und halten
Der SSL-Labs-Server-Test (Qualys) ist der Industriestandard für die Bewertung der TLS-Konfiguration. Er prüft die Zertifikatskette, die unterstützten Protokolle und Cipher-Suites, die HSTS-Konfiguration und bekannte Schwachstellen wie BEAST, POODLE und Heartbleed. Das Ergebnis ist eine Note von A+ bis F. Für einen Online-Shop sollte das Ziel A+ sein -- erreichbar durch TLS 1.2/1.3 mit starken Ciphern, HSTS mit Preloading, OCSP Stapling und einer sauber konfigurierten Zertifikatskette.
Wir empfehlen, den SSL-Labs-Test monatlich durchzuführen und die Ergebnisse zu dokumentieren. Serverupdates, Konfigurationsänderungen oder auslaufende Intermediate-Zertifikate können das Rating unbemerkt verschlechtern. Die Integration in das Monitoring-System automatisiert diese Prüfung und warnt bei Abweichungen vom Ziel-Rating.
Security Headers: CSP, Permissions-Policy und mehr
Neben der TLS-Konfiguration spielen HTTP-Security-Header eine entscheidende Rolle für die Gesamtsicherheit. Der Content-Security-Policy-Header (CSP) definiert, welche Ressourcen von welchen Quellen geladen werden dürfen -- ein wirkungsvoller Schutz gegen Cross-Site-Scripting (XSS). Der Permissions-Policy-Header kontrolliert den Zugriff auf Browser-APIs wie Kamera, Mikrofon und Geolocation. Zusammen mit X-Content-Type-Options: nosniff, X-Frame-Options: DENY und dem Referrer-Policy-Header bilden diese Einstellungen eine mehrschichtige Sicherheitsarchitektur.
Laut einer Analyse des HTTP Archive setzen nur 22 Prozent (Projekterfahrung) der E-Commerce-Websites einen vollständigen Satz an Security-Headern ein (HTTP Archive, 2025). Ein fehlendes CSP ermöglicht es Angreifern, schädliches JavaScript über kompromittierte Drittanbieter-Skripte einzuschleusen -- selbst wenn die TLS-Verbindung einwandfrei verschlüsselt ist. Die professionelle Wartung konfiguriert alle relevanten Security-Header und testet sie regelmäßig auf korrekte Funktionalität.
Mixed Content erkennen und beheben
Mixed Content entsteht, wenn eine HTTPS-Seite Ressourcen über HTTP lädt -- Bilder, Stylesheets, JavaScript oder Fonts. Moderne Browser blockieren aktiven Mixed Content (JavaScript, iframes) vollständig und warnen bei passivem Mixed Content (Bilder). In beiden Fällen leidet die Benutzererfahrung und die Sicherheit: Ein HTTP-geladenes Script kann von einem Angreifer manipuliert werden, selbst wenn die Hauptseite über HTTPS ausgeliefert wird.
Die häufigsten Mixed-Content-Quellen in Online-Shops sind: Produktbilder, die mit absolutem HTTP-Pfad in der Datenbank gespeichert sind, eingebettete Inhalte von Drittanbietern (Videos, Maps, Widgets), hartkodierte URLs in Theme-Dateien und externe Tracking-Pixel, die noch über HTTP eingebunden sind. Ein systematischer Scan aller Seiten identifiziert alle Mixed-Content-Quellen.
Die Behebung erfolgt auf mehreren Ebenen: Datenbank-Update aller HTTP-URLs auf HTTPS, Theme-Anpassungen für hartkodierte Pfade, CSP-Header mit upgrade-insecure-requests als Fallback (Browser konvertiert HTTP-Anfragen automatisch zu HTTPS) und Prüfung aller Drittanbieter-Integrationen. Eine professionelle Wartung stellt sicher, dass auch nach Updates und Inhaltsänderungen kein neuer Mixed Content entsteht.
Neben dem offensichtlichen Mixed Content gibt es subtile Varianten, die schwerer zu erkennen sind: Font-Dateien, die über HTTP geladen werden, Tracking-Pixel mit HTTP-URLs in E-Mail-Templates, Favicon-Referenzen ohne Protokoll-Angabe und hardcodierte HTTP-URLs in Datenbank-Einträgen von CMS-Systemen. Eine systematische Suche in der Datenbank nach der Zeichenkette "http://" im Content-Bereich deckt diese versteckten Referenzen auf. Nach der Korrektur verhindert eine konsequente Content Security Policy mit der Direktive "upgrade-insecure-requests", dass neue HTTP-Referenzen unbemerkt hinzukommen -- der Browser wandelt automatisch alle HTTP-Anfragen in HTTPS um.
Zertifikats-Monitoring: Ablauf verhindern
Auch bei automatischer Erneuerung kann die Zertifikatserneuerung fehlschlagen -- DNS-Änderungen, Serverumzug, Firewall-Regeln oder Rate-Limits der Zertifizierungsstelle können den Prozess blockieren. Zertifikats-Monitoring ist die Sicherheitsebene, die diese Fehlschläge erkennt, bevor das Zertifikat abläuft und der Shop ausfällt.
Professionelles Zertifikats-Monitoring prüft täglich: die verbleibende Gültigkeit (Warnung bei weniger als 30 Tagen), die Zertifikatskette (fehlende Intermediate-Zertifikate verursachen Fehler auf bestimmten Geräten), die TLS-Konfiguration (keine unsicheren Protokolle oder Cipher) und den OCSP-Status (widerrufene Zertifikate erkennen). Die Integration in das Monitoring-System stellt sicher, dass Warnungen zeitnah bearbeitet werden.
Für Online-Shops mit mehreren Domains und Subdomains empfehlen wir ein zentrales Zertifikats-Inventar: Eine Übersicht aller aktiven Zertifikate mit Domain, Ausstellungsdatum, Ablaufdatum und Erneuerungsmethode. Dieses Inventar hilft, den Überblick zu behalten und sicherzustellen, dass keine Domain vergessen wird. Abgelaufene Zertifikate auf Subdomains -- etwa dem Staging-System oder der API -- können überraschende Probleme verursachen, die bei der Fehlersuche viel Zeit kosten.
Die professionelle Verwaltung von SSL-Zertifikaten geht weit über das reine Zertifikat hinaus. Sie umfasst die TLS-Konfiguration, HSTS, Mixed-Content-Prüfung und kontinuierliches Monitoring. Für einen Online-Shop, dessen gesamtes Geschäft von der HTTPS-Erreichbarkeit abhängt, ist diese umfassende SSL-Verwaltung kein technisches Detail, sondern geschäftskritische Infrastruktur. Die Investition in eine professionelle Zertifikatsverwaltung vermeidet nicht nur Ausfälle, sondern optimiert auch Performance und Sicherheit der TLS-Verbindung -- mit messbaren Vorteilen für Ladezeit und Suchmaschinenranking.
OCSP Stapling: Zertifikatsvalidierung beschleunigen
Bei jedem TLS-Handshake prüft der Browser, ob das Zertifikat widerrufen wurde. Ohne OCSP Stapling sendet der Browser eine separate Anfrage an den OCSP-Responder der Certificate Authority -- das kostet 30 bis 100 Millisekunden (Projekterfahrung) pro Verbindungsaufbau und ist ein Datenschutzproblem, weil die CA erfährt, welche Websites der Nutzer besucht. Mit OCSP Stapling heftet der Server die aktuelle OCSP-Antwort an den TLS-Handshake an. Der Browser erhält die Gültigkeitsbestätigung direkt vom Server, ohne zusätzlichen Roundtrip.
Die Konfiguration von OCSP Stapling ist in modernen Webservern unkompliziert und sollte zum Standard jeder SSL-Verwaltung gehören. In der Server-Konfiguration werden zwei Direktiven aktiviert: die OCSP-Stapling-Funktion selbst und die OCSP-Verifizierung der gehefteten Antwort. Zusätzlich muss der Server die vollständige Zertifikatskette kennen, damit er die OCSP-Anfrage korrekt signieren kann. Ein regelmäßiger Test über SSL Labs bestätigt, dass OCSP Stapling aktiv ist -- der Report zeigt den Status unter "OCSP Stapling: Yes".
CAA-Records und Certificate Transparency
CAA-Records (Certification Authority Authorization) sind DNS-Einträge, die festlegen, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. Ohne CAA-Records kann jede der über 200 öffentlich vertrauenswürdigen Zertifizierungsstellen weltweit ein gültiges Zertifikat für Ihre Domain ausstellen -- eine Angriffsfläche, die durch einen einfachen DNS-Eintrag erheblich reduziert werden kann. Für Shops, die Let's Encrypt verwenden, lautet der Eintrag: 0 issue "letsencrypt.org".
Certificate Transparency (CT) ist ein öffentliches Protokollsystem, das die Ausstellung jedes SSL-Zertifikats dokumentiert. Durch die Überwachung der CT-Logs können Shop-Betreiber erkennen, ob unautorisierte Zertifikate für ihre Domain ausgestellt wurden -- ein mögliches Anzeichen für einen Man-in-the-Middle-Angriff. Professionelle Monitoring-Lösungen integrieren die CT-Log-Überwachung und benachrichtigen sofort bei verdächtigen Zertifikatsausstellungen.
- Let's Encrypt oder kommerzielles Zertifikat mit automatischer Erneuerung einrichten
- TLS 1.2 als Minimum, TLS 1.3 als Standard konfigurieren
- HSTS-Header mit max-age=31536000 und includeSubDomains aktivieren
- Alle Seiten auf Mixed Content prüfen und bereinigen
- CAA-Records im DNS setzen, um autorisierte Zertifizierungsstellen einzuschränken
- Security-Header (CSP, Permissions-Policy, X-Frame-Options) konfigurieren
- Monatlichen SSL-Labs-Test durchführen und A+-Rating sicherstellen
- Zertifikats-Monitoring mit 30-Tage-Vorwarnung einrichten
Quellen und Studien