Hybrid-Zertifikate aufbauen — klassisch und PQC parallel

Composite, Catalyst oder Multi-Cert — was geht heute, was kommt, was vermeidest du besser

Kurzfassung vorab

Hybrid-Zertifikate sind die Brückentechnologie zwischen klassischer Kryptografie und der Post-Quantum-Welt. Drei Architekturen konkurrieren um die Krone: Composite ML-DSA (ein Zertifikat mit kombinierter Signatur, der saubere Endzustand), Catalyst oder Dual-Use (ein Zertifikat mit zwei Signaturen, eine in einer X.509-Extension) und Multi-Cert (zwei separate Zertifikate für dasselbe Subject). Nur eines dieser drei Modelle lässt sich heute in einer ADCS-Umgebung produktiv aufbauen — und es ist nicht das eleganteste, sondern das pragmatischste.

Das pragmatische Modell heißt Multi-Cert. Zwei parallele Issuing-CAs, zwei Zertifikatsvorlagen pro Use Case, eine Anwendung, die beide Zertifikate vorhält und je nach Gegenstelle das passende aussucht. Composite ML-DSA ist als IETF-Draft schon ziemlich reif, aber weder ADCS noch CNG sprechen es bisher. Catalyst-Zertifikate hat die IETF längst zugunsten von Composite zu den Akten gelegt. Wer also heute ein Hybrid-Setup pilotieren will, baut Multi-Cert — und plant Composite für den Zeitpunkt ein, an dem Microsoft es liefert.

Abb. 1: Die drei Hybrid-Konzepte im Vergleich — Composite als Zukunft, Catalyst als historische Sackgasse, Multi-Cert als der einzige heute funktionsfähige Weg in ADCS.

1. Drei Hybrid-Konzepte in sechzig Sekunden

Bevor wir in die Details gehen, eine kompakte Einordnung der drei Architekturen — damit klar ist, wovon hier eigentlich die Rede ist:

Die drei Modelle adressieren denselben Use Case auf sehr unterschiedlichen Abstraktionsebenen. Composite ist die kryptografisch sauberste Lösung — eine OID, eine Signatur, ein Verifikationsergebnis. Catalyst ist ein Kompromiss aus einer Zeit, in der noch unklar war, ob PQC-Signaturen die klassischen vollständig ersetzen oder nur ergänzen sollten. Multi-Cert ist Brute Force: man macht einfach beides, einmal klassisch und einmal PQ, und überlässt der Anwendung die Auswahl.

2. Composite ML-DSA — der saubere Zukunfts-Endzustand

Composite ML-DSA löst ein elegantes Problem elegant: Wie bekomme ich zwei Algorithmen in ein Zertifikat, ohne dass bestehende Anwendungen, Protokolle und Parser umgebaut werden müssen? Antwort: Ich pretende, dass es nur einen Algorithmus gibt — und der Algorithmus heißt eben „MLDSA65-ECDSA-P256-SHA512" oder „MLDSA87-RSA4096-PSS-SHA512". Eine OID, ein Public Key, eine Signatur, ein Verifier-Ergebnis. Was unter der Haube passiert, ist Sache der Krypto-Bibliothek.

Abb. 2: Composite-Zertifikat im Detail — der ML-DSA-Anteil sitzt vorne mit fester Länge, der klassische Anteil dahinter mit variabler Länge.

Die Spezifikation definiert sieben konkrete Kombinationen — von ML-DSA-44 mit RSA-PSS bis ML-DSA-87 mit Ed448. Jede Kombination hat eine eigene OID, eine eigene Signatur-Berechnung und ein eigenes Verifier-Verfahren. Für ADCS heißt das: Composite ist nicht ein Algorithmus, sondern eine Familie von Algorithmen. Microsoft müsste für jede Variante eine CNG-Implementierung und einen ADCS-Template-Eintrag liefern. Stand Mai 2026 ist das nicht der Fall — kein einziges Composite-Algorithmus-Set ist in ADCS auswählbar.

3. Catalyst / Dual-Use — warum es das nicht geworden ist

Catalyst-Zertifikate sind die ältere Idee. Schon 2019 hatte die ITU-T in der X.509-Aktualisierung das Konzept verankert, dass ein Zertifikat zusätzliche Signaturen in non-critical Extensions transportieren kann. PQ-aware Clients prüfen die Zusatzsignatur und gewinnen damit Quantum-Resistenz; PQ-unaware Clients ignorieren die Extension und verlassen sich auf die klassische Signatur — kein Bruch, keine Anwendungsänderung.

Klingt schön, hat aber zwei Schwächen. Erstens ist die PQ-Signatur in der Extension nicht durchgängig in die Vertrauenskette eingebunden — sie ist eher ein Anhang als ein integraler Bestandteil. Zweitens kann ein Angreifer die Extension stripping (oder die CA hat sie nie eingebaut), und der Client merkt davon nichts. Das widerspricht dem Designziel von Hybrid-Zertifikaten: gerade die PQ-Komponente soll garantiert geprüft werden, sonst lohnt sich der ganze Aufwand nicht.

Die IETF hat diesen Konflikt erkannt und das Catalyst-Konzept im LAMPS-Working-Group-Kontext zu den Akten gelegt. Die Aktivität konzentriert sich auf Composite. Catalyst-Zertifikate werden in einigen frühen Test-PKIs noch herumgereicht, aber als langfristige Strategie verfolgt sie niemand mehr. Wer 2026 Migrations-Konzepte erstellt, kann den Catalyst-Ansatz ohne schlechtes Gewissen ignorieren.

4. Multi-Cert — der einzige praktische Weg heute

Multi-Cert ist das, was du baust, wenn du heute eine Hybrid-fähige PKI willst und nicht zwei Jahre warten kannst, bis Composite produktiv supportet wird. Die Idee ist so simpel wie pragmatisch: Du betreibst zwei parallele Issuing-CAs — eine klassische mit RSA und ECDSA, eine PQ-CA mit ML-DSA — und stellst für jedes Subject zwei Zertifikate aus. Die Anwendung hält beide Zertifikate vor und präsentiert je nach Gegenstelle das passende.

Abb. 3: Multi-Cert in einer ADCS-Umgebung — zwei parallele Issuing-CAs, koordiniert über Active Directory, Endgerät hält beide Zertifikate.

Das ist nicht elegant. Du hast doppelten Lifecycle (zwei Ausstellungen, zwei Renewals, zwei Widerrufe pro Identität), du brauchst zwei Templates pro Use Case, und die Anwendungslogik muss explizit lernen, dass es zwei Zertifikate gibt. Aber es funktioniert — heute, mit ADCS, ohne dass Microsoft etwas Neues liefern muss. Für jeden, der pilotieren oder PQ-Kompatibilität als Anwendungs-Probe aufbauen will, ist das der Weg.

In TLS-Szenarien hilft die Tatsache, dass moderne TLS-Server schon lange mehrere Zertifikate gleichzeitig vorhalten und nach Client-Capabilities auswählen können — IIS via Server Name Indication und Cipher-Suite-Matching, Nginx und Apache mit mehreren ssl_certificate-Direktiven, F5 und HAProxy nativ. Bei User-Zertifikaten und Geräte-Authentifizierung ist die Lage schwieriger: Hier müssen die Clients ihre Auswahl-Logik kennen — was bei Outlook anders aussieht als bei einem Linux-Daemon oder einem IoT-Gerät.

5. Multi-Cert in ADCS aufsetzen — die zwei parallelen Templates

Das Setup für Multi-Cert in ADCS folgt dem normalen Template-Workflow, nur eben zweimal — einmal klassisch, einmal PQ. Voraussetzung: Du hast Windows Server 2025 mit Mai-2026-Update und eine PQ-fähige Issuing-CA bereits eingerichtet (siehe Spoke 6.3 für die Pilot-CA-Installation). Die folgende Sequenz duplikatziert ein Web-Server-Template und stellt es einmal mit RSA-2048, einmal mit ML-DSA-65 zur Verfügung.

Wichtig: Die ML-DSA-Templates müssen Version 4 sein — Version 3 versteht den Algorithmus nicht. Wer die Templates aus einem v2-Original kopiert, bekommt zwar das Template erzeugt, aber das CA-Enrollment scheitert mit kryptischer Fehlermeldung. Wenn ein Pilot in den ersten Tagen partout nicht laufen will, ist das in der Praxis der häufigste Grund. Die Template-Versionen erkläre ich übrigens detailliert in Spoke 3.2 — dort steht auch, wann v3 reicht und wann v4 zwingend ist.

6. Stolperfallen im Multi-Cert-Setup

Multi-Cert ist konzeptionell einfach, operativ tückisch. Die folgenden sechs Punkte sind die typischen Stolperer aus echten Pilotprojekten:

7. Wann kommt Composite — die realistische Roadmap

Composite ML-DSA ist nicht „in zehn Jahren irgendwann", sondern hat einen erkennbaren Zeitplan. Drei Bewegungen müssen zusammenkommen, bevor du Composite produktiv in ADCS einsetzen kannst: Erstens muss der IETF-Draft RFC werden. Der aktuelle Draft 16 vom April 2026 expired im Oktober 2026; ein finaler RFC ist Ende 2026 oder Anfang 2027 plausibel. Zweitens muss CNG die Composite-Algorithmen ergänzen — Microsoft hat das in Aussicht gestellt, aber kein konkretes Datum kommuniziert. Drittens muss ADCS die Composite-OIDs in den Template-Dropdowns anbieten. Geschätztes Eintreffen für die ganze Kette: nicht vor 2027, realistisch Anfang 2028.

Was bedeutet das für eine Architekturentscheidung heute? Multi-Cert hat eine Halbwertszeit. Du baust es als Brückenlösung, nutzt es ein bis drei Jahre, und migrierst dann auf Composite, sobald die ADCS-Unterstützung da ist. Die gute Nachricht: Die operativen Lerneffekte aus dem Multi-Cert-Pilot — Anwendungskompatibilität, MTU-Verhalten, Renewal-Pipelines — übertragen sich vollständig auf Composite. Wer Multi-Cert produktiv hat, hat den schwierigsten Teil der PQ-Migration im Wesentlichen schon geschafft.

Abb. 4: Entscheidungsbaum — die Antwort hängt davon ab, ob du heute produktiv musst und ob du eine atomare Signatur brauchst.

Praxis-Beispiel · Musterwerk GmbH

Die Musterwerk GmbH, klassischer Industrie-Mittelstand mit 1.200 Mitarbeitern an drei Standorten, hat im Sommer 2026 die Hybrid-Frage in einem Architektur-Workshop angepackt. Die Ausgangslage: Eine zweistufige ADCS-Hierarchie mit RSA-4096-Offline-Root und RSA-2048-Issuing-CA, 90 produktive Webserver, davon 60 mit internen Standard-Geschäftsanwendungen und 30 mit Spezial-Apps aus dem Maschinenbau, deren Hersteller seit Jahren keine Updates mehr liefert. Eine reine PQ-Migration wäre für letztere Gruppe ein Wartungsdrama — die Geräte können noch nicht einmal SHA-256 sauber verifizieren.

Die Entscheidung fiel auf Multi-Cert mit klarer Scope-Trennung. Eine zweite Issuing-CA mit ML-DSA-65 wurde aufgesetzt, parallel zur bestehenden klassischen Issuing-CA. Die 60 modernen Webserver bekamen via Auto-Enrollment beide Zertifikate (klassisch und PQ); die 30 Spezial-Server bleiben bei rein klassischen Zertifikaten, bis die Hersteller-Updates kommen oder die Geräte ohnehin abgelöst werden. Der Aufwand: rund zwölf Personentage für CA-Setup, Template-Konfiguration und Test-Rollout an einem Pilot-Cluster mit zehn Servern.

Wichtigste Erkenntnis aus der Pilotphase: Die F5-Load-Balancer vor dem internen ERP-Cluster fragmentierten die ML-DSA-Signaturen, weil ein altes HTTP-Header-Größenlimit (8 KB) ungeprüft seit 2019 stand. Die Korrektur war eine Konfigurationszeile, das Aufspüren des Problems war anderthalb Tage Ursachenforschung. Hätte die Musterwerk diesen Effekt erst beim produktiven Rollout entdeckt, wäre es ein Outage-Ticket mit Audit-Diskussion geworden. So ist es eine ruhige Anekdote in der Architektur-Dokumentation.

Verwandte Themen

Häufige Fragen (FAQ)

Was ist der praktische Unterschied zwischen Composite und Multi-Cert?

Composite verpackt klassische und PQ-Komponenten in ein einziges Zertifikat — eine OID, eine Signatur, ein Vertrauensergebnis. Multi-Cert stellt zwei separate Zertifikate aus, die unabhängig voneinander verwaltet werden müssen. Composite ist eleganter, Multi-Cert ist heute machbar. Wer die Wahl hat, nimmt Composite; wer sie nicht hat, baut Multi-Cert.

Kann ADCS heute schon Composite ML-DSA?

Nein. Stand Mai 2026 unterstützt ADCS reine ML-DSA-Zertifikate (über das Mai-2026-Update), aber keine Composite-Varianten. Microsoft hat Composite in den Quantum-Safe-Roadmap-Aussagen genannt, aber kein konkretes Liefer-Datum kommuniziert. Realistisch wird das frühestens 2027 verfügbar, eher 2028.

Was ist die einfachste praktische Methode für Hybrid heute?

Multi-Cert mit zwei parallelen Issuing-CAs. Das ist das einzige Hybrid-Modell, das heute mit Standard-Microsoft-Mitteln aufgebaut werden kann. Operativer Mehraufwand ist real, aber überschaubar — und der Pilot bringt den größten Lernertrag im Bereich Anwendungskompatibilität, der sich später auf Composite überträgt.

Wann werde ich Composite-Zertifikate in der Microsoft-Welt sehen?

Drei Voraussetzungen müssen zusammenkommen: Der IETF-Draft wird RFC (erwartet Ende 2026 / Anfang 2027), Microsoft erweitert CNG um die Composite-Algorithmen, und ADCS bekommt die OIDs in die Template-Dropdowns. Realistischer Zeitpunkt für produktive Verfügbarkeit: Mitte 2027 bis Anfang 2028. Wer heute plant, sollte Composite als Zielarchitektur einkalkulieren, aber nicht darauf warten.

Brauche ich für Multi-Cert wirklich zwei separate Issuing-CAs?

Technisch könntest du eine einzige Issuing-CA mit zwei verschiedenen Algorithmen-Templates betreiben — aber dann hast du das Problem, dass die CA selbst ihren Schlüssel mit nur einem Algorithmus hat. Sauberer ist die Trennung: Eine CA mit klassischem Schlüsselmaterial signiert die klassischen Endentitäten, eine CA mit ML-DSA-Schlüsselmaterial signiert die PQ-Endentitäten. Das macht auch die Vertrauenskette eindeutig und vereinfacht die spätere Composite-Migration.

Was passiert, wenn eine Anwendung beide Zertifikate sieht?

Bei modernen TLS-Servern (IIS ab 10, Nginx, Apache, F5, HAProxy) entscheidet der Server anhand der Client-Capabilities, welches Zertifikat er ausliefert. Bei Outlook und Adobe Reader (S/MIME) hängt es von der Konfiguration ab — meistens muss man explizit auswählen. Bei IoT-Geräten ist die Antwort: Pro Gerät nur eines, denn deren Stack ist normalerweise nicht hybrid-fähig.

Nächste Schritte mit boddenberg.de

Hybrid-Setups sind operativ anspruchsvoll und bringen jedes Mal Lerneffekte mit sich, die in Standard-Migrationsleitfäden nicht stehen. Drei Pakete, die hier sinnvoll sind:

Wer Multi-Cert produktiv betreibt, sollte sich CertBinder für die atomare TLS-Erneuerung ansehen (Spoke 5.2) — bei zwei parallelen Zertifikatsketten ist das Renewal-Risiko verdoppelt, und genau dort hilft CertBinder. Außerdem in Arbeit: das PKI-Buch „PKI und Zertifikate in modernen Microsoft-Umgebungen", in dem die Hybrid-Migration in einem eigenen Kapitel ausführlich behandelt wird.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund