Die Automatisierung von Zertifikaten war über Jahre hinweg ein relativ stabiler und vorhersehbarer Bestandteil des TLS-Ökosystems. ACME – das ursprünglich von Let’s Encrypt eingeführte Protokoll – wurde zum De-facto-Standard für automatische Verlängerungen und die Ausstellung von Zertifikaten. Seine Architektur basierte auf einem einfachen Modell: Schlüsselgenerierung, CSR-Erstellung, Domainvalidierung, Zertifikatabruf. Im Jahr 2025 reicht dieses Modell nicht mehr aus. Mit dem Aufkommen von PQC (Post-Quantum Cryptography), hybriden Zertifikaten, OpenSSL 3.x und zunehmend strengeren CA/B-Forum-Richtlinien steht die automatisierte Zertifikatsumgebung vor der größten Veränderung seit zwei Jahrzehnten.

Die Migration zu Hybrid-TLS bedeutet, dass ACME eine völlig neue Klasse von Operationen unterstützen muss: die Generierung von zwei Schlüsseln, der Aufbau eines CSR, das klassische und postquantische Algorithmen kombiniert, die Verarbeitung großer SPKI-Strukturen sowie das Management von Zertifikaten, deren Größe und Parameter bisherige Grenzen überschreiten. ACME 3.0, obwohl noch nicht formell benannt, ist eine Notwendigkeit – keine Option.

1. Zertifikatsautomatisierung in einer Welt zweier paralleler Kryptografien.

Die wichtigste Veränderung besteht darin, dass das Zertifikat kein Monolith mehr ist. In der postquantischen Welt existiert es in hybrider Form: ein ECDSA-Teil für die Kompatibilität mit bestehenden Clients und ein PQC-Teil (Kyber, Dilithium oder deren Nachfolger) als Grundlage der zukünftigen Widerstandsfähigkeit gegen Quantenangriffe. Das bedeutet, dass ACME nicht länger ein Ein-Schlüssel- und Ein-CSR-System sein kann.

In Hybrid-TLS beeinflusst die Verkettung zweier Algorithmen jede Phase:

• Schlüsselgenerierung,
• CSR-Erstellung,
• Strukturvalidierung,
• Aushandlung des Handshakes,
• Validierung durch die CA,
• Verlängerungen,
• Schlüsselrotation in DevOps-Pipelines.

Im klassischen ACME war der gesamte Prozess linear. Ein hybrides Zertifikat erzwingt jedoch eine neue Architektur, in der der ACME-Client zu einem Werkzeug wird, das mehrere kryptografische Operationen gleichzeitig orchestriert. Dies ist die größte Revolution im TLS-Ökosystem seit dem Übergang von SHA-1 zu SHA-256.

2. Warum ACME in seiner aktuellen Form PQC nicht bewältigen kann?

Die Gründe sind vielfältig – und keiner davon ist trivial. Das heutige ACME-Protokoll entstand zu einer Zeit, als Zertifikate leichtgewichtig waren, CSRs nur wenige hundert Bytes groß waren und RSA 2048 der Standard war. Im Jahr 2025 wird dieser Standard zum Anachronismus.

Das erste Problem ist die Größe kryptografischer Strukturen. Kyber erzeugt Schlüssel, die um Größenordnungen größer sind als ECDSA. Hybrid-SPKI kann ein Vielfaches der klassischen Größe erreichen. Ein CSR, das zwei Algorithmen und zwei Signaturstrukturen enthält, hat ein Volumen, das früher als Fehler gewertet worden wäre.

Das zweite Problem ist die Unterstützung von KEM (Key Encapsulation Mechanism). Im Gegensatz zur klassischen asymmetrischen Kryptografie erfordert PQC eine Verkapselungsoperation, die das Material zur Ableitung von Sitzungsschlüsseln erzeugt. Die Einbettung in einen hybriden Handshake bedeutet, dass ACME zusätzliche Strukturkomponenten erzeugen und validieren muss.

Das dritte Problem ist die Kompatibilität der Werkzeuge. Die meisten ACME-Clients liefen über Jahre hinweg auf OpenSSL 1.0.x und 1.1.x. PQC ist mit diesen Bibliotheken nicht kompatibel – und wird es nie sein. Dies bedeutet, dass praktisch das gesamte ACME-Werkzeugökosystem neu aufgebaut werden muss: Certbot, acme.sh, LEGO, Posh-ACME, win-acme und zahlreiche Implementierungen in K8s-Controllern.

Das vierte Problem ist die Verifikation. ACME wurde zur Domainvalidierung entwickelt, nicht zur Validierung hybrider Algorithmusstrukturen. Eine CA muss die Korrektheit beider Schlüsselsätze, die Einhaltung der CP/CPS-Richtlinien sowie die interne Integrität des hybriden CSR bestätigen. Das verändert die CA-Architektur und die Prozesse, die ACME unterstützen muss.

3. Hybrider CSR: das neue Gravitationszentrum der Automatisierung

In der PQC-Ära wird der CSR zum problematischsten Element der Automatisierung. In der klassischen Welt reichten ein einzelner Schlüssel und ein einziges Subject Public Key Info-Feld aus. Heute muss ein CSR enthalten:

• einen klassischen Schlüssel (ECDSA),
• einen PQC-Schlüssel (Kyber oder einen anderen NIST-Finalisten),
• eine kombinierte SPKI-Struktur,
• kodierte PQC-Erweiterungen,
• Parameter, die den Signaturtyp definieren,
• gegebenenfalls PQC-spezifische OIDs.

Dies ist kein leichter Textcontainer mehr – sondern eine komplexe Struktur, die Bibliotheken erfordert, die das neue Format generieren und validieren können. ACME muss daher um Prozesse zur Erstellung, Signierung, Validierung und Serialisierung hybrider CSRs erweitert werden. Wenn die Automatisierung dies nicht berücksichtigt, wird ein hybrides Zertifikat nicht ausgestellt – oder schlimmer: es wird erst beim Handshake abgelehnt, was zu schwer debugbaren Fehlern führt.

4. Domainvalidierung in der PQC-Welt – mehr als nur ein trivialer Challenge

PQC führt auch neue Risiken im Validierungsprozess ein. ACME wurde mit der Annahme entwickelt, dass Domainvalidierung eine einfache Operation ist: HTTP-01, DNS-01 oder TLS-ALPN-01. Der neue Handshake-Modell und die große Zahl fehlerhafter PQC-Implementierungen führen jedoch dazu, dass ACME präziser sein muss, um zu erkennen:

• fehlerhafte SPKI-Strukturen,
• inkompatible PQC-KEM-Implementierungen,
• hybride Zertifikate, die nicht spezifikationskonform erzeugt wurden,
• unvollständige PQC-Erweiterungen.

Die Domainvalidierung bleibt gleich – aber die CSR-Validierung wird zu einem völlig neuen operativen Bereich, für den ACME 1.x und 2.x nicht ausgelegt waren.

5. Schlüsselrotation in DevOps-Pipelines: Automatisierung unter Druck

Die größte Herausforderung wird nicht der Handshake sein. Sie wird auch nicht die CA sein. Das größte Problem werden automatische Zertifikatsverlängerungen. Der 60-90-Tage-Automatisierungszyklus – etwas, das über Jahre banal war – wird plötzlich zu einem der komplexesten Prozesse im DevOps-Bereich.

Die CI/CD-Pipeline muss:

1. den ECDSA-Schlüssel generieren.
2. den PQC-Schlüssel generieren (z. B. Kyber 768).
3. beide zu einer hybriden Schlüsselstruktur zusammenführen.
4. einen CSR erstellen, der der CA-Policy entspricht.
5. ihn über ACME senden.
6. bislang unbekannte Fehler behandeln (z. B. zu großer Payload).
7. serverseitig prüfen, ob der Handshake funktioniert.
8. das Zertifikat auf Produktionsservern ersetzen.
9. das Zertifikat an Edge, CDN, API-Gateway, MQTT, IoT ersetzen.

Dies ist eine völlig andere Realität als das klassische „certbot renew“. In der Praxis werden viele Unternehmen erst 2025-2027 entdecken, dass sie hunderte Orte haben, an denen Schlüssel und Zertifikate verteilt werden – und dass jeder einzelne an die neue Realität angepasst werden muss.

6. Handshake-Größe und Auswirkungen auf Edge, CDN und Load Balancer

Hybrid-TLS erzeugt größere Handshake-Pakete, was eine Kette von Problemen auslöst:

• IoT-Geräte mit zu kleinen Puffern,
• ältere Load Balancer, die große ClientHello-Pakete als verdächtig einstufen,
• WAF-Systeme, die PQC-Handshakes als „Anomalie“ blockieren,
• CDNs, die größere Schlüsselstrukturen unterstützen müssen.

ACME in seiner klassischen Form hat all dies nicht berücksichtigt. Mit PQC muss es nicht nur ein Protokoll zur Zertifikatsautomatisierung werden, sondern auch ein Werkzeug zur Sicherstellung der Konsistenz der gesamten Zertifikatsdistribution in Edge-Umgebungen.

7. ACME 3.0 – wie wird es aussehen?

Auch wenn die Spezifikation noch nicht veröffentlicht ist, zeichnen sich bestimmte Muster aus den Entwicklungen der CAs und TLS-Anbieter ab. ACME 3.0 wird wahrscheinlich umfassen:

• Unterstützung für mehralgorithmische CSRs,
• Standardisierung der SPKI-Strukturen für PQC,
• Validierungsmechanismen für PQC-Algorithmen,
• größere Payload-Grenzen,
• neue Transportmethoden (HTTP/2, HTTP/3),
• native Integration mit DevOps-Pipelines,
• Vorabprüfung hybrider Zertifikate vor der Ausstellung,
• zusätzliche OID-Strukturen für PQC.

Der wichtigste Unterschied liegt jedoch anderswo: ACME wird zu einem Protokoll der kontinuierlichen Compliance, nicht einer einmaligen Domainvalidierung.

8. Sind Unternehmen bereit für ACME nach PQC?

Nein. Die überwiegende Mehrheit der Organisationen verfügt nicht über:

• aktuelle kryptografische Bibliotheken,
• modernisierte DevOps-Pipelines,
• kompatible K8s-Controller,
• aktualisierte Edge-Geräte,
• HSM-Ressourcen mit PQC-Unterstützung.

Die kommenden Jahre werden die größte technische Transformation in der Geschichte der TLS-Zertifikate markieren.

9. Fazit: ACME ist nicht mehr nur ein „Zertifikat-Tool“. Es ist das Fundament der Infrastruktur-Sicherheit.

Die PQC-Ära macht die Zertifikatsautomatisierung zu einem hochriskanten technischen Bereich. Unternehmen, die ACME nicht für hybride Algorithmen anpassen, werden Folgendes erleben:

• Fehler bei Verlängerungen,
• nicht funktionierende Handshakes,
• Inkonsistenzen zwischen Umgebungen,
• inkompatible Zertifikate,
• Probleme in CDN-Regionen,
• Incidents in IoT und Edge,
• Nichteinhaltung der CA/B-Forum-Richtlinien.

Im Jahr 2025 durchläuft ACME eine Transformation ohne historischen Präzedenzfall. Was jahrelang ein technisches Detail war, wird zu einem der zentralen Elemente der Resilienz im postquantischen Zeitalter.