In den letzten zehn Jahren verlief die Entwicklung der Netzwerkkryptografie eher evolutionär. Wir aktualisierten OpenSSL-Bibliotheken, ersetzten SHA-1 durch SHA-256, erhöhten RSA-Schlüssellängen – aber all dies blieb innerhalb eines bekannten Sicherheitsmodells. Im Jahr 2025 stehen wir zum ersten Mal seit über 20 Jahren vor einer Veränderung, die keine Evolution ist. Es ist ein Reset der TLS-Architektur.

Der Eintritt der postquantensicheren NIST-Algorithmen wie CRYSTALS-Kyber und Dilithium bedeutet eine Veränderung auf fundamentaler Ebene. Es geht nicht mehr um die Wahl der Kurve, die Schlüssellänge oder das Signaturformat. Es geht um die Tatsache, dass das bisherige System für Schlüsselaustausch und digitale Signaturen nicht mehr ausreichend sicher sein wird, sobald Quantencomputer eine ausreichende Rechenleistung erreichen. Und viele der heute abgefangenen Daten werden auch in zehn Jahren noch relevant sein. Aus diesem Grund beginnt die Sicherheitswelt, das Modell „harvest now, decrypt later“ als reale Bedrohung zu betrachten und nicht als Futurologie.

Hybrides TLS: kein Experiment, sondern ein Übergangsstandard.

Die wichtigste Herausforderung besteht darin, dass eine Migration nicht „auf einmal“ erfolgen kann. Browser, Betriebssysteme, IoT-Geräte, Embedded-Infrastrukturen und kryptografische Bibliotheken sind im Jahr 2025 nicht in der Lage, reines PQC zu unterstützen. Deshalb wurde das hybride Modell eingeführt, bei dem der TLS-Handshake zwei parallele Mechanismen für den Schlüsselaustausch umfasst: einen klassischen (ECDHE) und einen postquantenfähigen (Kyber). Client und Server verhandeln beide Parametersätze und kombinieren sie anschließend zu einem Sitzungsschlüssel, der sowohl gegen klassische als auch gegen Quantenangriffe resistent ist.

Genau in diesem Moment stellen viele Organisationen fest, dass ihr Netzwerk – obwohl es einwandfrei funktioniert – nicht bereit ist, größere Handshake-Records, neue OIDs und doppelte Schlüsselstrukturen zu verarbeiten. Im hybriden Modell steigen die Paketgrößen, das CPU-Profil verschiebt sich und einige Edge-Geräte haben Probleme mit dem Parsen der neuen TLS-Erweiterungen. Dies erfordert Tests, Kompatibilitätsanalysen und bewusstes Planen.

OpenSSL 3.x: notwendige Voraussetzung, keine Empfehlung.

Einer der häufigsten Fehler in Unternehmensinfrastrukturen ist die Annahme, dass die Aktualisierung von OpenSSL eine Frage der Bequemlichkeit und nicht der Sicherheit sei. Dabei ist OpenSSL 1.1.1 – über Jahre der De-facto-Standard – inkompatibel mit den neuen PQC-Mechanismen. Es kann keine kryptografischen Provider laden, besitzt keine modulare Architektur und unterstützt moderne Schlüsseltypen nicht.

OpenSSL 3.x führt die Provider-Architektur ein, unterstützt das dynamische Laden neuer Algorithmen, moderne Signaturtypen und bietet die Flexibilität, die hybride Handshakes erfordern. Daher ist die Migration kryptografischer Bibliotheken keine „Option für später“. Sie ist die Voraussetzung für jegliche PQC-Tests, selbst nur experimentelle.

Änderung der X.509-Zertifikatsformate: ein neues Kapitel für die PKI.

Die Welt der Zertifikate steht vor der größten Neukonzeption seit zwei Jahrzehnten. Im postquantensicheren Modell reicht ein einzelner öffentlicher Schlüssel im Zertifikat nicht mehr aus. Ein X.509-Zertifikat wird zwei Parametersätze enthalten müssen: einen klassischen ECDSA-Teil und eine postquantenfähige Komponente.

Das bedeutet eine Neustrukturierung der gesamten Toolchain: von CSR-Generatoren über CAs bis hin zu Browsern und CT-Logs. Ein CSR wird nicht mehr ein leichtes Dokument mit einem Schlüssel sein, sondern eine Struktur ähnlich einem Container, der mehrere Algorithmen umfasst. Browser müssen verstehen, wie Signaturen interpretiert werden, CAs müssen beide Strukturen validieren und CT-Systeme müssen deutlich größere Zertifikate speichern können.

Konsequenzen für Serverinfrastrukturen: was ändert sich wirklich?

Dies ist keine Änderung „auf Zertifikatsebene“. Sie betrifft alle Komponenten der Infrastruktur:

• TLS-Server und Reverse Proxys,
• WAF- und Load-Balancer-Geräte,
• kryptografische Bibliotheken in Backend-Systemen,
• mobile und Desktop-Clients,
• IoT-Umgebungen (ein kritischer Punkt ist MTU und die Größe der Handshake-Records),
• HSMs, die für Schlüsselerzeugung und -schutz verantwortlich sind.

In vielen Unternehmen werden HSMs zum größten Engpass. Ein beträchtlicher Teil der heute eingesetzten Hardwaremodule unterstützt Kyber oder Dilithium nicht, und deren Modernisierung erfordert den Austausch der gesamten Hardware, nicht nur ein Firmware-Update. Zukünftige Zertifikate werden größer sein, ihre Erzeugung wird kryptografisch schwerer, und der Zertifizierungsprozess wird länger, da CAs doppelte Strukturen validieren müssen.

Migrationsmodell: wie erfolgt der Übergang zu PQC-Ready TLS?

Der Übergang zu quantenresistentem TLS erfolgt nicht „per Klick“. In der Praxis erfordert er drei parallele Arbeitsströme:

1. Modernisierung der Kryptografie (Bibliotheken, Server, HSM).

Organisationen müssen prüfen, ob alle Komponenten PQC-Provider laden und Schlüssel in neuen Formaten generieren können. Genau hier treten oft scheinbar kleine Probleme auf – etwa ein Backend, das seit Jahren mit einer alten LibTLS-Version läuft, oder ein IoT-Gerät, das größere Handshake-Frames nicht akzeptiert.

2. Interoperabilitätstests.

PQC verlangt Tests nicht nur mit Browsern, sondern auch mit Proxys, über die interne Systeme kommunizieren. Tests des hybriden Handshakes müssen im öffentlichen Internetverkehr und in internen Umgebungen stattfinden, die APIs, Microservices und sogar Datenbankkommunikation umfassen.

3. Vorbereitung neuer DevOps-Pipelines.

Pipelines müssen zwei Schlüsselpaare generieren, hybride CSRs verarbeiten, sie an die CA senden und doppelte Signaturen validieren. Viele CI/CD-Werkzeuge sind dafür nicht vorbereitet. Dies ist ein Schritt, den Organisationen oft unterschätzen – und erst bei Massenverlängerungen feststellen, dass der Prozess „auseinanderfällt“.

Warum das alles jetzt und nicht erst 2027 erledigt werden muss?

Zwischen 2026 und 2028 entsteht Druck seitens:

• Browsern (Chrome Root Program wird hybride Zertifikate bevorzugen),
• dem CA/B Forum (Dual-Algorithm für OV/EV),
• Regulierungsbehörden (besonders Finanz- und Regierungssektor),
• Geschäftspartnern (PQC-Kompatibilität in Integrationsprotokollen).

Unternehmen, die nicht vorbereitet sind, finden sich in einer Situation wieder, die dem Wechsel von SHA-1 zu SHA-256 ähnelt – inkompatible Infrastruktur, zahlreiche Handshake-Fehler und immenser Zeitdruck.

Zusammenfassung: die Migration zu PQC ist ein Dreijahresprojekt, keine Wochenendumstellung.

Die Vorbereitung der Infrastruktur auf PQC bedeutet:

• Modernisierung kryptografischer Bibliotheken,
• Aktualisierung von Servern und Reverse Proxys,
• Hardwareüberprüfung (insbesondere HSM),
• Pipeline-Vorbereitung für doppelte Schlüssel,
• Kompatibilitätstests mit Browsern und Geräten,
• Bereitschaft für neue X.509-Zertifikatsformate,
• Kontrolle der Auswirkungen auf Performance und Handshake-Größe.

Dies ist ein Prozess, der – wenn er jetzt begonnen wird – ruhig und schrittweise durchgeführt werden kann, ohne teure Fehler. Wird er jedoch zu spät angegangen, wird PQC zu einem Infrastrukturproblem statt einem kryptografischen.

Case Studies: wie reale Umgebungen auf die erste PQC-Welle reagieren.

Obwohl die vollständige Implementierung postquantensicherer Kryptografie gerade erst beginnt, treten bereits heute Probleme auf, die aus PQC-Tests oder aus der Kollision moderner Bibliotheken mit klassischen Infrastrukturen entstehen. Die folgenden Case Studies stammen aus Audits und Migrationsprojekten der Jahre 2023-2025 in Europa und den USA.

Case Study 1: Bank Load Balancer, der Teile der TLS-Hybrid-Pakete nicht „sah“.

Eine große Bank, die PQC testweise einführte, bemerkte, dass ein Teil der Verbindungen der mobilen App mit einem Reset oder Handshake-Renegotiation endete. Zunächst vermutete man ein Problem in der App oder im Zertifikat. Eine detaillierte PCAP-Analyse zeigte jedoch:

• das eingesetzte L4/L7-Appliance hatte einen festen Grenzwert für TLS-Record-Größen,
• hybride Handshake-Records waren um etwa 35-45% größer,
• das Gerät interpretierte Teile des Verkehrs als Fragmentierung einer „verdächtigen Sitzung“ und verwarf Pakete.

Man ging davon aus, dass ein Firmware-Update ausreiche.
Der Hersteller informierte jedoch, dass PQC-Unterstützung erst 2027 verfügbar sein werde.

Ergebnis: Austausch des gesamten Gerätepools, der noch vor zwei Jahren als „neu“ galt.

Case Study 2: Medizinisches IoT-Ökosystem mit TLS 1.2, das mit Kyber nicht zurechtkam.

Ein Hersteller von Telemetriegeräten setzte TLS 1.2 mit ECDHE/ECDSA ein, was 2021 medizinische Standards erfüllte. Bei PQC-Tests zeigte sich:

• 18% der Embedded-Geräte akzeptierten das hybride ClientHello nicht,
• einige ESP32-basierte Mikrocontroller hatten feste Puffergrenzen,
• der TLS-Stack konnte nicht erweitert werden, ohne das Firmware neu zu entwickeln.

Die PQC-kompatible Firmware erforderte:

• Änderung des TLS-Stacks,
• Austausch einiger Kommunikationsmodule,
• erneute medizinische Zertifizierung (Kosten im siebenstelligen Bereich).

Dies zeigt das größte Risiko von PQC in regulierten Branchen: Zeit und Kosten der Gerätezertifizierung.

Case Study 3: Enterprise-CDN, das PQC nur auf modernen Edge-Nodes aktivierte.

Ein großer CDN-Betreiber führte PQC-Tests im HTTPS-Verkehr durch. Die Ergebnisse:

• ein Teil älterer Edge-Knoten konnte OpenSSL 3.2 nicht unterstützen,
• neuere Regionen funktionierten problemlos,
• der größere Handshake verursachte gelegentliche Timeouts in Regionen mit schlechter Netzqualität.

Die endgültige Strategie war ebenfalls hybrid: PQC wurde nur in modernisierten Regionen aktiviert, während ältere Knoten klassische Algorithmen nutzen.

Dies ist ein früher Beleg für das Modell „PQC per region capability“, das zwischen 2025 und 2030 weit verbreitet sein wird.

Case Study 4: interne PKI eines Softwarehauses, das keinen hybriden CSR erzeugen konnte.

Ein großes Softwareunternehmen mit eigener SaaS-Plattform betrieb eine interne CA auf Basis alter OpenSSL-Versionen. Beim Versuch, einen hybriden CSR zu erzeugen, stellte man fest:

• dass die CA keine PQC-Provider unterstützt,
• dass Automatisierungswerkzeuge nur RSA/ECDSA verarbeiten,
• dass die CI/CD-Pipeline CSRs im Format von 2015 generiert.

Um PQC einzuführen, musste das Unternehmen:

• das gesamte Issuing-CA-System neu bauen,
• die Zertifikatspipeline modernisieren,
• CP/CPS-Policies anpassen,
• DevOps-Skripte überarbeiten,
• die Integration mit dem Zertifikatsmonitoring neu gestalten.

Dieses Fallbeispiel zeigt die wichtigste Erkenntnis: PQC-Probleme entstehen oft nicht im TLS-Layer, sondern in der gesamten PKI-Organisation.

Auswirkungen von PQC auf ACME, Zertifikatsautomatisierung und DevOps-Pipelines.

In der Zeit vor PQC war die Zertifikatsautomatisierung relativ einfach. ACME generierte einen einzelnen CSR, holte das Zertifikat ab, verlängerte es automatisch und DevOps überwachte nur den Prozess. Im postquantensicheren Modell müssen ACME und die gesamte Pipeline zwei parallele kryptografische Strukturen handhaben, neue OIDs verarbeiten, größere Payloads übertragen und komplexere Validierungen durchführen.

ACME in der Welt hybrider Zertifikate.

ACME wurde in einer Zeit entworfen, in der ein Zertifikat einen Schlüssel und eine Signaturstruktur hatte. Ein hybrides PQC-Zertifikat bedeutet, dass ein CSR folgende Elemente enthalten wird:

• den klassischen Teil (ECDSA),
• den PQC-Teil (Kyber),
• zusätzliche X.509-Erweiterungen,
• größere SPKI-Strukturen.

Moderne ACME-Server (z. B. Boulder von Let’s Encrypt) sind noch nicht vollständig PQC-fähig. Die Migration von ACME bedeutet:

• Erzeugung zweier Schlüsselpaare,
• Kombination zu einem gültigen hybriden CSR,
• Unterstützung erheblich größerer Datenmengen,
• Anpassung der Signaturvalidierung auf CA-Seite.

Dies erfordert auch die Modernisierung der ACME-Clients wie Certbot, acme.sh, Lego oder Posh-ACME.

Auswirkungen von PQC auf DevOps- und CI/CD-Pipelines.

In der Praxis wird PQC nicht zuerst den Webserver treffen. Es trifft die DevOps-Pipeline.

Der Grund ist einfach: bisher generierte die Pipeline einen Schlüssel und einen CSR. In der PQC-Welt muss die Pipeline zwei Schlüsselpaare erzeugen und komplexe Abhängigkeiten verwalten.

Dies bedeutet Änderungen in:

• CSR-Generatoren (OpenSSL, step-ca, Custom Scripts),
• GitHub/GitLab-Integrationen,
• Build-Containern,
• Policy-Enforcement-Linien,
• Schlüsselrotation.

Zusätzlich wird die Pipeline:

• die PQC-Komponenten von Zertifikaten validieren,
• zwei Schlüssel sicher speichern,
• größere Artefakte verarbeiten,
• hybride CSRs an CAs übertragen.

Dies ist eine enorme Herausforderung für Unternehmen, die den Lebenszyklus von Zertifikaten bisher nicht automatisiert haben.

Automatische Zertifikatsverlängerungen: das Ende eines einfachen Prozesses.

Die automatische Zertifikatsrotation (z. B. alle 60 oder 90 Tage) war bisher trivial. In der PQC-Ära bedeutet eine Erneuerung:

• Neuerzeugung beider Schlüsselpaare,
• Regenerierung des hybriden CSR,
• Durchführung eines PQC-kompatiblen ACME-Flows,
• Überprüfung der Kompatibilität mit allen Clients.

In den ersten PQC-Jahren wird Automatisierung die größte technische Herausforderung sein – nicht der TLS-Handshake selbst.