TLS und Zertifikate: Checkliste für Server und Websites

TLS verschlüsselt Verbindungen zu Websites, Mail- und VPN-Servern und Geräten; das Zertifikat belegt, dass der Server zum Namen gehört. Neben den Laufzeiten (Abschnitt 02) ändert sich 2026 die BSI-Empfehlung: Die TR-02102-2, Version 2026-01 vom 27. Jänner 2026, empfiehlt TLS 1.2 nur noch bis Ende 2031, weil dafür voraussichtlich keine quantensicheren Schlüsseleinigungsverfahren standardisiert werden (Abschnitt 3.2).

Die Baseline Requirements binden Zertifizierungsstellen, sobald Browser- und Softwarehersteller sie durchsetzen (Abschnitt 1.1). § 32 NISG 2026 schreibt kein bestimmtes Verfahren vor, verlangt aber geeignete, verhältnismäßige Maßnahmen nach dem Stand der Technik (Abs. 1 und 2).

Die CAs sollen jeweils einen Tag darunter bleiben (199, 99, 46 Tage), weil ein Tag 86 400 Sekunden hat und schon Bruchteile darüber als weiterer Tag zählen (Abschnitt 6.3.2). Geprüfte Unternehmensangaben für OV-Zertifikate dürfen seit 15. März 2026 höchstens 398 statt 825 Tage wiederverwendet werden (4.2.1); für EV gelten nach den EV Guidelines (3.2.2.14.3) schon seit 2021 höchstens 398 Tage. SC-081v3 wurde am 11. April 2025 ohne Gegenstimme angenommen.

• Bei 47 Tagen braucht jeder Name mindestens acht Zertifikate im Jahr, und bei 10 Tagen ist die Domain-Prüfung praktisch jedes Mal neu fällig. Let’s Encrypt rät von manueller Erneuerung ab; auch der Nachweis muss automatisch laufen (Abschnitt 04).
• Bei kompromittiertem Schlüssel und einigen weiteren Gründen, etwa unzuverlässiger Domain-Prüfung, muss die CA binnen 24 Stunden sperren, in anderen Fällen binnen 5 Tagen (Abschnitt 4.9.1.1). Ein Tausch muss also jederzeit kurzfristig gehen.

Let’s Encrypt verkürzt früher (Ankündigung vom 2. Dezember 2025): Profil tlsserver seit 13. Mai 2026 mit 45 Tagen; Standardprofil classic ab 10. Februar 2027 mit 64 Tagen und 10 Tagen Wiederverwendung der Domain-Prüfung (bestätigt am 7. Oktober 2026), ab 16. Februar 2028 mit 45 Tagen und 7 Stunden; Profil shortlived mit rund 6 Tagen.

TLSRef ist der Nachfolger des Mozilla SSL Configuration Generator (ssl-config.mozilla.org leitet weiter, laut Mozilla betreut eine Community-Arbeitsgruppe außerhalb von Mozilla das Projekt). Intermediate erlaubt die Signatur sha256WithRSAEncryption (PKCS #1 v1.5); wer der TR-02102-2 eng folgt, prüft die Kette und wählt ECDSA bei einer CA mit ECDSA-Zwischenzertifikat.

ACME (RFC 8555) ist der IETF-Standard für Antrag, Domain-Nachweis und Erneuerung ohne Handarbeit; ob Ihre CA ihn anbietet, steht in ihrer Dokumentation. Die gebräuchlichsten Wege für den Nachweis per ACME (weitere wie dns-account-01, Baseline Requirements 3.2.2.4.21, kommen hinzu):

• Erneuerung terminieren: am besten nach ACME Renewal Information (ARI, RFC 9773), dann schlägt die CA ein Zeitfenster vor, etwa früher vor einer Massensperrung. Ohne ARI nennt Let’s Encrypt die Erneuerung nach etwa zwei Dritteln der Laufzeit als geeignet; feste 60 Tage reichen bei 45 Tagen nicht.
• Einsetzen und neu laden: Der Dienst muss das neue Zertifikat laden, auch auf Load Balancer, Firewall oder Appliance. Nach der ersten automatischen Erneuerung mit den Befehlen aus Abschnitt 07 prüfen.
• Ausfälle melden lassen: Let’s Encrypt empfiehlt eine Überwachung, die Alarm gibt, wenn nicht wie erwartet erneuert wird. TOMORIS empfiehlt, von außen zu prüfen, was der Dienst ausliefert.

Bestätigung per Telefon oder E-Mail läuft aus: Die Baseline Requirements schließen die Domain-Prüfung per Telefon ab 15. März 2027 aus (3.2.2.4.16, 3.2.2.4.17), per E-Mail an Kontakte wie admin@ ab 15. März 2028 (3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14; Ballot SC-090).

Für Einrichtungen nach dem NISG 2026 verlangt die DVO (EU) 2024/2690 (über § 2 NISV 2026) ein Konzept für das Schlüsselmanagement, soweit angemessen unter anderem für Ausstellung und Erlangung von Public-Key-Zertifikaten, Schlüsselwechsel, Widerruf und Aktivierungsfristen (Anhang Nr. 9.2 lit. c, Punkte ii, v, vii und xii). Ein Inventar ist dafür die einfachste Grundlage und nützt jedem Unternehmen.

• Alle Namen erfasst, auch Subdomains, Fernzugänge und Zertifikate bei Hostern oder Dienstleistern; unter Erneuerung steht „ACME“ oder der manuelle Ablauf mit Termin.
• Unbekannte Zertifikate gesucht: Certificate Transparency (RFC 6962) protokolliert ausgestellte Zertifikate öffentlich; eine Suche nach Ihren Domains zeigt Zertifikate außerhalb des Inventars.
• Überwachung von außen je Dienst und Port; TOMORIS empfiehlt eine Warnung bei einem Drittel Restlaufzeit und Alarm bei sieben Tagen, an eine Gruppe statt an eine Person.

Drei Bausteine sorgen dafür, dass Besucher nur verschlüsselt verbinden und nur die gewünschte Zertifizierungsstelle ausstellen darf: Weiterleitung, HSTS und CAA.

• Weiterleitung: Port 80 leitet dauerhaft auf dieselbe Adresse mit https um, etwa mit Status 301 (RFC 6797, Abschnitt 7.2) oder 308 wie bei TLSRef; die Apache-Vorlage nimmt /.well-known/acme-challenge/ aus.
• HSTS: Strict-Transport-Security mit max-age (Pflicht) und optional includeSubDomains, nur über HTTPS senden (RFC 6797, Abschnitte 6.1 und 7.2); RFC 9325 empfiehlt es Webservern (Abschnitt 3.2).
• In Stufen einführen: hstspreload.org nennt 5 Minuten, 1 Woche und 1 Monat, vorher alle Subdomains prüfen, auch interne. Danach empfiehlt TOMORIS ein Jahr (31536000 Sekunden), TLSRef setzt zwei Jahre. Von der Preload-Liste rät hstspreload.org inzwischen ab.

Mit HSTS wird jeder Zertifikatsfehler zur Sperre: Der Browser muss etwa bei einem abgelaufenen Zertifikat abbrechen und soll kein Fortfahren anbieten (RFC 6797, Abschnitte 8.4 und 12.1). HSTS braucht deshalb eine Ablaufüberwachung.

CAA-Einträge (RFC 8659) legen fest, welche Zertifizierungsstellen für eine Domain ausstellen dürfen; sie gelten auch für Subdomains ohne eigenen Eintrag (Abschnitt 3). Öffentliche CAs müssen sie prüfen, seit 15. März 2026 mit DNSSEC-Validierung, wo eingerichtet, und ab 15. März 2027 accounturi und validationmethods auswerten (RFC 8657; Baseline Requirements 4.2.2.1 und 4.2.2.2). Den Namen Ihrer CA nennt deren Certification Practice Statement.

; nur diese Zertifizierungsstelle darf ausstellen, keine Wildcards
example.at. IN CAA 0 issue "ca.example.net"
example.at. IN CAA 0 issuewild ";"
example.at. IN CAA 0 iodef "mailto:security@example.at"

; enger (RFC 8657): STATT der ersten issue-Zeile, nicht zusätzlich, da CAA additiv wirkt
; (RFC 8659, 4.2); accounturi=<Konto-URL> bindet zusätzlich an ein ACME-Konto
example.at. IN CAA 0 issue "ca.example.net; validationmethods=dns-01"

# nach TLSRef Configurator (Leitlinien 6.0), Profil Intermediate (nginx 1.27.3, OpenSSL 4.0.1, HSTS)
http {
    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        http2 on;
        ssl_certificate /pfad/zertifikat_plus_zwischenzertifikate;
        ssl_certificate_key /pfad/privater_schluessel;
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    }

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
    ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;

    # HTTP dauerhaft auf HTTPS umleiten
    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        return 308 https://$host$request_uri;
    }
}

# nach TLSRef Configurator (Leitlinien 6.0), Apache 2.4.60; braucht mod_ssl, mod_rewrite, mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [R=308,QSA,L]
</VirtualHost>
<VirtualHost *:443>
    SSLEngine on
    # SSLCertificateFile und SSLCertificateKeyFile wie gewohnt
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1
SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20
SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLHonorCipherOrder off
SSLSessionTickets off

Die Cipher-Liste steht in OpenSSL-Kurzform (+ heißt „und“) und ergibt dieselben sechs Suiten wie im Configurator, prüfbar mit openssl ciphers -v. X25519MLKEM768 erst ab OpenSSL 3.5. Die Zertifikatsdatei enthält auch die Zwischenzertifikate. Eng nach TR-02102-2: ohne ChaCha20 und reines X25519, SecP256r1MLKEM768 oder SecP384r1MLKEM1024 voranstellen (ab OpenSSL 3.5), mit ECDSA.

Windows-Server mit IIS nutzen Schannel. Laut Microsoft Learn sind TLS 1.0 und 1.1 auch unter Windows Server 2025 standardmäßig aktiviert; TLS 1.3 gibt es ab Windows Server 2022. Abschalten mit dem DWORD-Wert Enabled = 0 in den Unterschlüsseln TLS 1.0\Server und TLS 1.1\Server unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols; danach kann ein Neustart des Dienstes nötig sein. Microsoft rät, möglichst Gruppenrichtlinien statt direkter Registry-Änderungen zu nutzen.

# Verbindung: Protokoll, Cipher Suite, Gruppe, Zertifikat
openssl s_client -connect www.example.at:443 -servername www.example.at -brief </dev/null

# Gegenprobe, muss scheitern (erwartet: "alert protocol version"). OpenSSL 3.x sperrt
# TLS 1.0/1.1 schon ab Sicherheitsstufe 1 (Standard 2), daher nur hier Stufe 0
openssl s_client -connect www.example.at:443 -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' -brief </dev/null
openssl s_client -connect www.example.at:443 -tls1 -cipher 'DEFAULT:@SECLEVEL=0' -brief </dev/null

# Aussteller, Namen, Ablauf; Exit-Code ungleich 0, wenn es in 14 Tagen abläuft
openssl s_client -connect www.example.at:443 -servername www.example.at </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName -checkend 1209600

# vom Server gesendete Kette (ungeprüft, in Senderreihenfolge)
openssl s_client -connect www.example.at:443 -servername www.example.at -showcerts </dev/null

# Mailserver mit STARTTLS
openssl s_client -connect mail.example.at:25 -starttls smtp -brief </dev/null

• Mail: Gibt es einen eigenen TLS-Port und STARTTLS, ist laut RFC 9325 der TLS-Port vorzuziehen, bei reinem STARTTLS eine strikte Richtlinie ohne Klartext-Rückfall (Abschnitt 3.2); zwischen Mailservern nennt RFC 9325 MTA-STS.
• VPN: in geschlossenen Systemen ist laut BSI meist eine beidseitige Authentisierung notwendig (TR-02102-2, Abschnitt 3.5). Drucker, NAS, Hypervisor, Switches: Weboberfläche prüfen, Firmware aktualisieren, TLS 1.0 und 1.1 abschalten, wo möglich.
• Interne Namen wie server.firma.local: Dafür stellen öffentliche CAs nicht aus (Baseline Requirements 4.2.2). Eigene PKI oder öffentliche Namen nutzen; für eine eigene PKI gelten die Baseline Requirements nicht (1.1).

• TLS 1.3 aktiv und bevorzugt, TLS 1.2 nur mit ECDHE und AEAD; TLS 1.0, 1.1, SSL 2.0 und 3.0 auf allen Diensten aus und mit openssl s_client gegengeprüft.
• Keine Suiten mit RSA-Schlüsseltransport, DH oder DHE (TLS_RSA_*, TLS_DH_*, TLS_DHE_*, RFC 10015), kein statisches ECDH, kein RC4, 3DES oder NULL; 0-RTT, Kompression und Heartbeat aus.
• Schlüssel ECDSA P-256 oder P-384 oder RSA ab 3000 Bit (BSI), mindestens 2048 Bit; Signatur SHA-256 oder stärker; privater Schlüssel geschützt gespeichert (BSI, Abschnitt 4.1).
• Vollständige Kette ausgeliefert (-showcerts); subjectAltName deckt alle genutzten Namen ab.
• Jedes öffentliche Zertifikat samt Domain-Nachweis per ACME, Erneuerung nach ARI oder bei zwei Dritteln der Laufzeit, danach neu laden; Ausnahmen bis 15. März 2027 umstellen.
• Inventar mit Ablauf, Erneuerungsweg und Zuständigkeit, auch bei Hostern; CT-Logs geprüft.
• HTTP leitet dauerhaft auf HTTPS um; HSTS mindestens ein Jahr, includeSubDomains erst, wenn alle Subdomains HTTPS können.
• CAA-Einträge für alle Domains mit den genutzten Zertifizierungsstellen und einer iodef-Adresse.
• Mail, VPN, Drucker, NAS und weitere Geräte geprüft und im Inventar; interne Namen über eine eigene PKI; Software kommt ohne OCSP aus.
• Jährlich gegen TR-02102-2 und TLSRef geprüft; hybride Schlüsseleinigung bis Ende 2031 geplant.