SSL-Zertifikat einrichten & HTTPS-Umstellung

Viele Websitebetreiber glauben, HTTPS sei nur für Online-Shops relevant. Das ist falsch. Die Datenschutz-Grundverordnung verpflichtet jeden, der personenbezogene Daten verarbeitet, zu angemessenen technischen Schutzmaßnahmen. Sobald Ihre Website ein Kontaktformular, eine Newsletteranmeldung, einen Login oder ein Bestellformular enthält, fallen Name, E-Mail-Adresse und alle weiteren Eingaben unter DSGVO Art. 32. Die Pflicht gilt unabhängig von Branche, Unternehmensgröße oder Umsatz – maßgeblich ist allein, dass personenbezogene Daten über die Website übertragen werden.

DSGVO Art. 32: Verschlüsselung als gesetzliche Anforderung

DSGVO Art. 32 Abs. 1 lit. a nennt ausdrücklich die Verschlüsselung personenbezogener Daten als geeignete technische Maßnahme, die dem Stand der Technik entsprechen muss. Der Hamburger Datenschutzbeauftragte hat klargestellt: Jede unverschlüsselt aufrufbare Seite und jede unverschlüsselt nachgeladene Ressource – auch Bilder, Stylesheets oder JavaScript-Dateien – stellt einen Verstoß gegen Art. 32 DSGVO dar. Verstöße gegen Art. 32 (technisch-organisatorische Maßnahmen) fallen unter den Bußgeldrahmen des Art. 83 Abs. 4 DSGVO: bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

BSI TR-02102-2: Der technische Standard für Deutschland

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert in der Technischen Richtlinie TR-02102-2 (Version 2026-01, veröffentlicht am 27.01.2026) konkret, welche TLS-Versionen und Cipher Suites als sicher gelten. Diese Richtlinie ist der maßgebliche technische Referenzpunkt für Webserver-Konfigurationen in Deutschland. Behörden, Banken und immer mehr private Auftraggeber setzen die Einhaltung vertraglich voraus. Die aktuelle Version verschärft gegenüber früheren Ausgaben insbesondere die Anforderungen an Schlüssellängen und Cipher-Auswahl: TLS 1.2 ist nur noch mit AEAD-Cipher-Suites zulässig, CBC-Modi gelten als nicht mehr empfohlen, und Perfect Forward Secrecy ist verpflichtend vorgeschrieben.

SSL-Zertifikate unterscheiden sich nicht nur im Preis, sondern vor allem im Validierungsumfang. Die Wahl des richtigen Zertifikatstyps hängt von Ihrem Geschäftsmodell und den Anforderungen Ihrer Zielgruppe ab. Ein teures Zertifikat bietet dabei keine stärkere Verschlüsselung als ein kostenloses – der Unterschied liegt ausschließlich in der Identitätsprüfung durch die Zertifizierungsstelle.

Technische Anforderungen an das Zertifikat selbst

Unabhängig vom Zertifikatstyp gelten technische Mindestvorgaben, die durch BSI TR-02102-2 und die Anforderungen gängiger Browser definiert werden. Die Schlüssellänge ist dabei ein häufig unterschätzter Parameter: Ein zu kurzer Schlüssel macht das Zertifikat angreifbar, selbst wenn die Konfiguration im Übrigen korrekt ist.

• Schlüssellänge: RSA mindestens 3000 Bit gemäß BSI TR-02102-2 Version 2026-01; empfohlen ECDSA mit 256 Bit (P-256), das einer RSA-Sicherheit von rund 3072 Bit entspricht bei deutlich kleinerer Schlüsselgröße und schnellerer Verarbeitung
• Signaturalgorithmus: SHA-256 mindestens – MD5 und SHA-1 sind veraltet und werden von Browsern mit einem Fehler abgelehnt
• Bei jeder Verlängerung: immer einen neuen Privatschlüssel generieren, niemals den alten wiederverwenden
• Wildcard-Zertifikate sparsam einsetzen: ein kompromittierter Subdomainserver gefährdet alle anderen Subdomains, die dasselbe Wildcard-Zertifikat nutzen
• CAA DNS-Record setzen: legt fest, welche Zertifizierungsstellen überhaupt Zertifikate für Ihre Domain ausstellen dürfen – ohne CAA könnte jede CA unautorisiert ein Zertifikat für Ihre Domain ausstellen
• OCSP Stapling aktivieren: beschleunigt die Sperrstatus-Prüfung und verhindert Privacy-Lecks gegenüber der CA, da der Browser den Sperrstatus nicht mehr selbst abfragen muss

Ein installiertes Zertifikat allein reicht nicht. Entscheidend ist die TLS-Konfiguration des Webservers: Welche Protokollversionen sind aktiviert? Welche Cipher Suites werden angeboten? Gibt es Perfect Forward Secrecy? Wer hier spart oder veraltete Standardkonfigurationen übernimmt, hinterlässt Angriffsfläche – und bekommt bei SSL Labs höchstens ein B. Eine A+-Bewertung setzt voraus, dass nicht nur das Zertifikat stimmt, sondern die gesamte Konfigurationsschicht darunter.

Erlaubte Protokollversionen

Empfohlene Cipher Suites

TLS 1.3 verwendet ausschließlich AEAD-Cipher-Suites und benötigt keine manuelle Konfiguration – der Standard ist hier bereits vollständig sicher. Bei TLS 1.2 ist die Auswahl dagegen entscheidend: Nur ephemere Schlüsselaustauschverfahren (ECDHE, DHE) gewährleisten Perfect Forward Secrecy. CBC-basierte Cipher Suites sind nach BSI TR-02102-2 Version 2026-01 für TLS 1.2 nicht mehr zulässig. Statische RSA-Schlüsselaushandlung (TLS_RSA_*) muss deaktiviert werden, weil sie keine PFS ermöglicht und bei späterer Schlüsselkompromittierung sämtliche gespeicherten vergangenen Sitzungen entschlüsselbar macht.

• TLS 1.3 (automatisch sicher, keine Konfiguration erforderlich): TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
• TLS 1.2 empfohlen (nur AEAD, nur ECDHE): TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• Zu deaktivieren: NULL-Cipher, Anonymous-Cipher (anon), EXPORT-Cipher, RSA-Transportverschlüsselung ohne PFS (TLS_RSA_*), statisches DH (TLS_DH_*, TLS_ECDH_*), alle CBC-basierten TLS-1.2-Suites
• SSL/TLS-Komprimierung deaktivieren (verhindert CRIME-Angriff auf Session-Cookies: SSLCompression off in Apache)

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy bedeutet: Selbst wenn der private Schlüssel eines Servers zu einem späteren Zeitpunkt kompromittiert wird, können aufgezeichnete vergangene Sitzungen nicht nachträglich entschlüsselt werden. Möglich wird dies durch ephemere Schlüssel (ECDHE, DHE), die nach jeder Sitzung verworfen werden und nirgendwo dauerhaft gespeichert sind. TLS 1.3 erzwingt PFS für alle Verbindungen – bei TLS 1.2 muss dies durch explizite Cipher-Suite-Auswahl sichergestellt werden. BSI TR-02102-2 Version 2026-01 macht PFS verpflichtend; eine Konfiguration ohne PFS gilt nicht mehr als BSI-konform.

TLS-Konfiguration testen

• SSL Labs Server Test (ssllabs.com/ssltest): Detaillierte Bewertung mit Schulnote A+ bis F, Analyse von Protokollen, Cipher Suites, Zertifikat und Header – das wichtigste Diagnosewerkzeug
• MDN HTTP Observatory (developer.mozilla.org/en-US/observatory): Fokus auf HTTP-Sicherheits-Header wie HSTS, CSP, X-Frame-Options
• sslyze (Python CLI, github.com/nabla-c0d3/sslyze): Skriptbarer Test für automatisierte Prüfungen in CI/CD-Pipelines und regelmäßige Scans
• Nach unserer Konfiguration: A oder A+ auf SSL Labs – das ist unser messbares Lieferziel, das wir durch den Screenshot des Testergebnisses belegen

Die größte Stolperfalle bei einer HTTPS-Umstellung ist Mixed Content: Die HTML-Seite wird über HTTPS ausgeliefert, Bilder, Stylesheets, Skripte oder Fonts werden aber noch über HTTP geladen. Moderne Browser blockieren aktiven Mixed Content (JavaScript, iFrames, XHR-Anfragen) vollständig – die Seite funktioniert dann nicht mehr korrekt, auch wenn das Zertifikat einwandfrei ist. Passiver Mixed Content (vor allem Bilder) erzeugt Warnungen und kann in künftigen Browser-Versionen ebenfalls vollständig blockiert werden. Mixed Content ist kein seltener Randfall: Er tritt bei praktisch jeder HTTPS-Umstellung auf, die ohne sorgfältige Datenbankmigration durchgeführt wird.

Typische Fehlerquellen bei der HTTPS-Umstellung

• Hardcodierte http://-URLs in CMS-Datenbanken (bei WordPress z. B. die Felder siteurl und home in der Tabelle wp_options sowie alle Media-Uploads und Inhaltslinks)
• CSS url()-Pfade in Theme-Stylesheets, die auf HTTP-Ressourcen wie Hintergrundbilder oder Fonts zeigen
• JavaScript-Variablen mit hardcodierten HTTP-URLs, häufig in Theme-Dateien oder Custom-Plugins
• Drittanbieter-Ressourcen (Google Fonts, CDN-Assets, Social-Widgets, Chat-Tools) ohne HTTPS-Unterstützung oder mit veralteten HTTP-Einbettungslinks
• WYSIWYG-Links im CMS-Editor, die bei der Migration nicht aktualisiert wurden und auf interne Seiten per HTTP verweisen
• Iframe-Einbettungen (YouTube, Google Maps, Vimeo) mit alten HTTP-Einbettungscodes
• Theme-interne Font-Referenzen, die direkt auf externe HTTP-Server zeigen statt auf lokale Kopien

1. 1

   Zertifikat installieren und HTTPS-Erreichbarkeit testen

   SSL-Zertifikat einrichten, Webserver für HTTPS konfigurieren, Erreichbarkeit unter https:// manuell prüfen, Zertifikatsdetails im Browser kontrollieren. Erst wenn HTTPS fehlerfrei erreichbar ist, folgen die weiteren Schritte.

2. 2

   Interne URLs und Datenbank migrieren

   Alle internen Links, Medienpfade und CMS-Datenbank-Einträge von http:// auf https:// oder protokollrelative Pfade umstellen. Bei WordPress: wp_options-Felder siteurl und home, alle Medienverweise, Inhaltslinks im post_content sowie Theme-Hardcodes. Bei TYPO3 und anderen CMS analog.

3. 3

   Mixed-Content-Scan durchführen

   Browser DevTools (Console-Tab auf der Live-Seite), Why-No-Padlock-Tool und SSL Labs Mixed Content Checker einsetzen. Jede HTTP-Ressource identifizieren, dokumentieren und beheben – der Scan muss alle Seitentypen abdecken, nicht nur die Startseite.

4. 4

   HTTP-zu-HTTPS-Redirect einrichten

   Permanente 301-Weiterleitung auf Webserverebene konfigurieren – in Apache via RewriteRule, in Nginx via return 301. Kein Redirect über CMS-Plugins, da diese erst nach vollständigem PHP-Start greifen und frühere Anfragen nicht erfassen.

5. 5

   HSTS-Header aktivieren

   Erst wenn 100 % aller Ressourcen und Subdomains über HTTPS erreichbar sind: Strict-Transport-Security-Header mit max-age=31536000 aktivieren. Dieser Schritt ist schwer rückgängig zu machen – daher erst nach vollständiger Prüfung.

6. 6

   SSL Labs Test und Abnahme

   Finaler Test auf ssllabs.com/ssltest: Ziel A oder A+. Ergebnis-Screenshot als Protokoll an den Auftraggeber übergeben. Monitoring für Zertifikatsablauf einrichten, damit eine Warnung 30 Tage vor Ablauf ausgelöst wird.

HSTS ist der stärkste Mechanismus, um SSL-Stripping-Angriffe zu verhindern. Beim SSL-Stripping leitet ein Angreifer im Netzwerk – etwa in einem offenen WLAN – HTTPS-Verbindungen auf HTTP um, ohne dass der Nutzer es bemerkt. HSTS verhindert das: Der Browser lernt, diese Domain immer direkt über HTTPS anzusprechen, ohne vorher eine HTTP-Verbindung aufzubauen. Das funktioniert, weil der Browser den HSTS-Eintrag lokal speichert und künftige Anfragen intern von http:// auf https:// umschreibt, bevor sie das Netzwerk erreichen.

Der HSTS-Header im Detail

Der Header lautet: Strict-Transport-Security: max-age=31536000; includeSubDomains. Der Wert max-age=31536000 entspricht einem Jahr – das ist die Mindestanforderung für das HSTS-Preloading. includeSubDomains bedeutet, dass der Schutz für alle Subdomains gilt; dieser Parameter darf nur gesetzt werden, wenn alle Subdomains zuverlässig HTTPS unterstützen. Fehlt auch nur eine einzige Subdomain ohne HTTPS, verlieren Nutzer nach HSTS-Aktivierung den Zugang zu dieser Subdomain vollständig, weil der Browser die HTTP-Verbindung verweigert und keine HTTPS-Alternative existiert.

HSTS Preloading: erhöhter Schutz, irreversibler Schritt

Über hstspreload.org können Domains in die browsereigene HSTS-Preload-Liste aufgenommen werden. Diese Liste ist direkt in Chrome, Firefox, Safari und Edge eingebaut – die HTTPS-Erzwingung gilt dann schon beim allerersten Besuch, ohne dass der Browser je einen HSTS-Header empfangen haben muss. Damit wird auch die erste Verbindung eines neuen Besuchers geschützt, bei der ohne Preloading noch kein HSTS-Eintrag im Browser vorliegt. Die Aufnahme in die Liste ist unkompliziert; die Entfernung dagegen dauert Monate bis Jahre und erfordert einen separaten Antrag. Preloading ist daher nur für Domains geeignet, bei denen dauerhaft und unwiderruflich HTTPS auf allen Subdomains sichergestellt ist.

In unserer Arbeit mit Unternehmenswebsites begegnen uns immer wieder dieselben Konfigurationsfehler. Keiner davon ist dramatisch schwer zu beheben – aber jeder hinterlässt eine Sicherheitslücke oder senkt die SSL-Labs-Bewertung. Besonders häufig finden wir Kombinationen mehrerer dieser Fehler, weil veraltete Standardkonfigurationen einfach nie aktualisiert wurden. Hier die typischen Befunde:

Was bei einem abgelaufenen Zertifikat passiert

Läuft ein SSL-Zertifikat ab, zeigen alle gängigen Browser eine große rote Warnseite – kein Nutzer kommt noch auf Ihre Website, ohne aktiv eine Ausnahme zu bestätigen, was die meisten verweigern. Suchmaschinen-Crawler verzeichnen Fehler und können Seiten nicht mehr crawlen; das beschädigt Indexierung und SEO-Trust. Bei Let's Encrypt-Zertifikaten mit ihrer 90-tägigen Laufzeit ist ein richtig eingerichtetes Auto-Renewal (Certbot Cron, Certbot systemd Timer oder ACME-Client im Hosting-Panel) zwingend. Wir richten das Monitoring so ein, dass Sie 30 Tage vor Ablauf informiert werden – als zweite Sicherheitsstufe neben der Automatisierung, falls das Auto-Renewal aus einem technischen Grund fehlschlägt.

Sie beauftragen uns mit der SSL-Einrichtung und HTTPS-Umstellung – wir übernehmen alles, von der Zertifikatsbeantragung bis zum abschließenden SSL-Labs-Test mit Dokumentation. Kein Stundensatz, kein offenes Ende, kein Abnahmestreit: Sie erhalten ein festes Ergebnis zu einem festen Preis, mit einem messbaren Qualitätskriterium – der SSL-Labs-Note.

1. 1

   Bestandsaufnahme Ihrer aktuellen Konfiguration

   SSL-Labs-Test Ihrer Domain, Analyse der aktuellen TLS-Version, Cipher Suites, Zertifikatstyp, Schlüssellänge, HSTS-Status und Mixed-Content-Situation. Schriftliche Befundliste vor Beginn der Arbeiten – Sie wissen genau, was gemacht wird und warum.

2. 2

   Zertifikat beantragen und installieren

   DV-Zertifikat via Let's Encrypt (kostenlos) oder kostenpflichtiges OV/EV-Zertifikat gemäß Ihren Anforderungen. Installation auf Ihrem Webserver, Konfiguration des Auto-Renewals mit Monitoring und Ablaufwarnung.

3. 3

   TLS-Konfiguration nach BSI TR-02102-2

   Deaktivierung unsicherer Protokolle und Cipher Suites, Aktivierung von TLS 1.3 und TLS 1.2 (nur AEAD), Perfect Forward Secrecy via ECDHE, OCSP Stapling, CAA-DNS-Record-Prüfung und ggf. Einrichtung – gemäß Mozilla SSL Config Generator und BSI-Standard Version 2026-01.

4. 4

   HTTPS-Umstellung und Mixed-Content-Bereinigung

   Migration aller internen URLs und Datenbankeinträge, Behebung aller identifizierten Mixed-Content-Fehler, Einrichtung des HTTP-zu-HTTPS-301-Redirects auf Webserverebene – nicht per CMS-Plugin.

5. 5

   HSTS-Aktivierung

   Erst nach vollständiger Prüfung aller Subdomains: HSTS-Header mit korrektem max-age, begründete includeSubDomains-Entscheidung und ggf. Vorbereitung für Preloading – mit klarer schriftlicher Aufklärung über die Konsequenzen und Irreversibilität.

6. 6

   Abnahme und Übergabedokumentation

   SSL-Labs-Ergebnis (A oder A+) als Screenshot, schriftliche Dokumentation aller Konfigurationsänderungen mit Dateipfaden und Parametern, Monitoring-Setup für Zertifikatsablauf. Sie erhalten eine vollständige, verständliche Zusammenfassung – auch für Ihren nächsten Dienstleister nachvollziehbar.