Wissen · TR-02102-2

Fristen der TR‑02102‑2: was Ende 2026 ausläuft

Die TR-02102-2 nennt zu jedem Verfahren ein Jahr, bis zu dem es empfohlen ist. Für einige Cipher-Suiten und einen TLS-1.3-Modus endet die Empfehlung am 31.12.2026. Zwei Signaturverfahren sind schon seit Ende 2025 nicht mehr empfohlen. Hier stehen alle Fristen der Fassung 2026-01 an einer Stelle, mit Fundstelle.

Stand: 01.11.2026 · Quellen: BSI TR-02102-2, Version 2026-01 vom 27.01.2026; unser Regelwerk-JSON mit Fundstelle je Eintrag; eigene Messung mit OpenSSL 3.5.7 am 01.11.2026

So sind die Fristen zu lesen

• Eine Jahreszahl heißt: empfohlen bis Ende dieses Jahres (Abschnitt 3.1.1, S. 6). „2026“ endet also am 31.12.2026.
• Ein „+“ hinter der Jahreszahl (hier „2032+“) heißt: Die Frist wird in einer künftigen Fassung womöglich verlängert. Ohne „+“ ist keine Verlängerung angekündigt.
• Was nach Ablauf nicht mehr empfohlen ist, wird dadurch nicht automatisch unsicher. Die TR sagt nur, dass sie es nicht mehr empfiehlt (Kapitel 1, S. 4). Wer sich in einem Audit oder Vertrag auf die TR beruft, muss die Abweichung aber begründen können.

Fristenkalender

Alle Einzeleinträge mit IANA-Nummer stehen auf der Seite TR-02102-2 als Tabelle.

Ende 2026: Wen das betrifft

Statische (EC)DH-Suiten (TLS_ECDH_*, TLS_DH_*, ohne das „E“ für ephemer) brauchen ein Zertifikat mit (EC)DH-Schlüssel und sind in Webserver-Konfigurationen selten. OpenSSL hat sie mit Version 1.1.0 entfernt. Wer sie findet, hat meist eine sehr alte Bibliothek oder eine Appliance; das ist der eigentliche Befund.

TLS_RSA_PSK_* kommt praktisch nur in Maschine-zu-Maschine-Verbindungen mit vorab verteilten Schlüsseln vor, nicht bei Webservern.

psk_ke betrifft die Wiederaufnahme von TLS-1.3-Sitzungen (Session Tickets zählen als PSK). OpenSSL nutzt bei der Wiederaufnahme standardmäßig psk_dhe_ke; psk_ke nur, wenn die Option SSL_OP_ALLOW_NO_DHE_KEX gesetzt ist (in openssl s_server: -allow_no_dhe_kex). Wer diese Option nicht selbst gesetzt hat, ist mit OpenSSL in der Regel nicht betroffen. Bei anderen Bibliotheken und bei Lastverteilern sollten Sie es nachprüfen.

Schon abgelaufen: RSA mit PKCS #1 v1.5

Diese Frist trifft mehr Server, weil sie zwei Stellen hat.

1. Die Handshake-Signatur in TLS 1.2. Bei ECDHE_RSA-Suiten signiert der Server den Schlüsselaustausch. Empfohlen ist dafür RSA-PSS (Tabellen 11 und 12), RSA mit PKCS #1 v1.5 nicht mehr. Wir haben am 01.11.2026 einen lokalen Testserver (openssl s_server, OpenSSL 3.5.7, RSA-3072, nur TLS 1.2) gemessen:

Mit aktuellen Clients signiert OpenSSL also schon mit RSA-PSS. Ein alter Client, der nur PKCS #1 v1.5 kennt, bekommt aber ohne Einschränkung weiter eine Signatur nach dem abgelaufenen Verfahren. Wer das abstellen will, beschränkt die Signaturverfahren. Das sperrt solche Clients dann aus.

2. Die Signatur in der Zertifikatskette. Tabelle 12 betrifft die Signaturen, mit denen die Zertifikate der Kette unterschrieben sind. Ein RSA-Zertifikat einer öffentlichen Zertifizierungsstelle ist in aller Regel mit sha256WithRSAEncryption signiert, also PKCS #1 v1.5. Darauf hat der Serverbetreiber nur über die Wahl des Zertifikats Einfluss, etwa mit einem ECDSA-Zertifikat. Auch unsere eigene Seite liefert eine ECDSA-Kette (Let’s Encrypt YE1 → Root YE → ISRG Root X2), aber das letzte mitgelieferte Zertifikat ist die Querzertifizierung von ISRG Root X2 durch ISRG Root X1, und die ist mit sha256WithRSAEncryption signiert. Clients, die ISRG Root X2 schon als Wurzel kennen, brauchen dieses Zertifikat nicht und prüfen seine Signatur nicht.

Konfiguration: Ende-2026-Einträge und PKCS #1 v1.5 ausschließen

Die Suiten aus Tabelle 4 und TLS_RSA_PSK_* verschwinden, wenn Sie TLS 1.2 nur mit den ECDHE-Suiten aus Tabelle 3 betreiben. Die vollständigen Zeilen stehen im Artikel nginx und Apache nach TR-02102-2 konfigurieren. Die Handshake-Signatur beschränken Sie zusätzlich so:

nginx (OpenSSL ab 1.1.1, nginx ab 1.19.4):

ssl_conf_command SignatureAlgorithms RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512;

Apache (2.4.x mit mod_ssl):

SSLOpenSSLConfCmd SignatureAlgorithms RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512

Prüfen Sie vorher, ob alte Clients, die Sie noch bedienen müssen, RSA-PSS können. Testen Sie mit nginx -t bzw. apachectl configtest.

Selbst prüfen

# Welche Signatur verwendet der Server bei TLS 1.2?
openssl s_client -connect beispiel.de:443 -tls1_2 </dev/null 2>/dev/null | grep "Peer signature type"
# Signiert er noch mit PKCS #1 v1.5, wenn der Client nur das anbietet? (Kommt keine Zeile, lehnt er ab.)
openssl s_client -connect beispiel.de:443 -tls1_2 -sigalgs RSA+SHA256 </dev/null 2>/dev/null | grep "Peer signature type"
# Womit sind die mitgelieferten Zertifikate signiert? (je Zertifikat: Inhaber, darunter die Signatur)
openssl s_client -connect beispiel.de:443 -showcerts </dev/null 2>/dev/null > kette.pem
openssl crl2pkcs7 -nocrl -certfile kette.pem | openssl pkcs7 -print_certs -text -noout | grep -E "^ {4}Signature Algorithm|Subject:"

Prüfen Sie nur eigene Server oder solche, für die Sie zuständig sind.

Grenzen

• Die Fristen stammen aus der Fassung 2026-01. Das BSI legt die TR in der Regel jährlich neu auf; die nächste Fassung kann Fristen verlängern oder Einträge ergänzen, etwa die angekündigten ML-KEM-Hybridgruppen (siehe ML-KEM-Hybride in TLS 1.3).
• Gemessen haben wir OpenSSL 3.5.7 lokal, nicht nginx, Apache oder andere Bibliotheken. Sitzt ein Lastverteiler oder CDN vor dem Server, entscheidet dessen TLS-Stack.
• Die Einordnung „selten“ für statische (EC)DH- und RSA-PSK-Suiten ist unsere Erfahrung, keine Zählung.
• Das Prüfprotokoll unseres Regelwerks beschreibt, wie die Fristen aus dem PDF übertragen und gegengeprüft wurden; maßgeblich ist allein das PDF des BSI.

Ob Ihr Server eines der auslaufenden Verfahren noch annimmt, misst der Bericht von außen, mit Frist und Fundstelle je Zeile. Ein Beispiel ist der Musterbericht. Konfigurationszeilen können Sie vorab kostenlos im Browser prüfen: TLS-Konfiguration prüfen.

Quellen: BSI TR-02102-2 (PDF) · Regelwerk-JSON und Prüfprotokoll · OpenSSL: SSL_CTX_set_options. Dieser Artikel ist keine Rechtsberatung und nicht vom BSI geprüft. Er fasst die genannten Quellen in eigenen Worten zusammen. Die Konfigurationszeilen sind Beispiele; testen Sie sie vor dem Einsatz in Ihrer Umgebung.