Sectigo hat am 14. April Private PQC angekündigt, ein Feature innerhalb von Sectigo Certificate Manager, das ML-DSA-signierte Zertifikate aus einer privaten CA ausstellt. Unterstützte Algorithmen sind ML-DSA-44, ML-DSA-65 und ML-DSA-87. Zertifikate durchlaufen den bestehenden SCM-Workflow für Freigaben, Auditing, Erneuerung und Widerruf. Das Signierungsmaterial liegt innerhalb der Sectigo-Infrastruktur hinter einem virtuellen HSM.
Die Technik ist solide, und das Feature ist ein ehrlich nützlicher On-Ramp für Teams, die ML-DSA-Material bereits durch ihren Zertifikatslebenszyklus laufen lassen wollen, bevor sie es in die öffentlich vertraute PKI bringen. Dieser Beitrag richtet sich an die nächste Frage, die eine CISO- oder Architektur-Ebene beim Lesen einer solchen Ankündigung stellt: Welchen Teil unseres PQC-Bedrohungsmodells deckt das ab, und welche Schichten brauchen weiterhin Aufmerksamkeit.
ML-DSA und ML-KEM adressieren unterschiedliche Bedrohungsmodelle
Das sind zwei der vier NIST-PQC-Standards, und sie schützen vor unterschiedlichen Dingen. Sie einmal nebeneinander in einem Migrationsplan abzulegen und danach wiederzuverwenden, lohnt sich.
ML-DSA ersetzt RSA und ECDSA in der Signaturkette von Zertifikaten. Es schützt die Authentifizierung gegen einen künftigen Angreifer, der Signaturen fälschen könnte. Das zählt für langlebige signierte Artefakte, Code Signing, Dokumentenattestierungen und Zertifikatsketten, die über die Ankunft eines kryptographisch relevanten Quantencomputers hinaus vertrauenswürdig bleiben müssen.
ML-KEM ersetzt ECDH und RSA-basierten Schlüsselaustausch im TLS-Handshake. Es schützt den Session-Schlüssel gegen Harvest-now-decrypt-later. HNDL ist das Szenario, in dem ein Angreifer heute Chiffretext erfasst, ihn speichert und den symmetrischen Session-Schlüssel Jahre später zurückgewinnt, wenn ein CRQC den Schlüsselaustausch bricht. Signaturauthentifizierung hat auf diesen Pfad keinen Einfluss. Ein mit ML-DSA signiertes Zertifikat authentifiziert den Server gegenüber dem Client. Es verändert weder, welchen Schlüssel die beiden Parteien ableiten, noch ob dieser Schlüssel aus einem erfassten Handshake rekonstruierbar ist.
Private PQC liefert ML-DSA. Ein Team, das es einsetzt, gewinnt quantensichere Zertifikatsauthentifizierung in der internen PKI. HNDL-Schutz für TLS-Verkehr kommt davon, ML-KEM im Handshake zu aktivieren (typischerweise hybrides ML-KEM mit einem klassischen Partner), und das ist ein separater Deployment-Schritt.
Beides gehört in den Migrationsplan. Wer weiß, welche Schicht was abdeckt, behält den Scope klar.
Was „Private“ im Produktnamen bedeutet
Private PQC stellt Zertifikate aus einer privaten CA aus: Sie hängen an einer Root, die nur innerhalb der Kundenumgebung vertraut wird. Diese Zertifikate sind hervorragend für interne Dienste, Code Signing, CI/CD-Artefakte und jeden Workflow, in dem der Kunde beide Enden der Vertrauenskette kontrolliert.
Öffentlich exponierte Endpunkte im Internet nutzen weiterhin Zertifikate von öffentlich vertrauten CAs. Stand heute haben diese öffentlichen CAs noch nicht im größeren Stil mit der Ausstellung von ML-DSA-Zertifikaten begonnen, und Browser und Ökosystem-Clients sind nicht breit so konfiguriert, ihnen zu vertrauen. Das wird sich in den nächsten Jahren ändern, und Sectigos Arbeit auf der privaten Seite ist ein sinnvoller Ort, um operative Routine aufzubauen, bevor die öffentliche Seite bereit ist.
Ein Team kann Private PQC heute produktiv für die interne PKI nutzen und gleichzeitig die öffentliche TLS-Konfiguration auf klassischen Zertifikaten halten. Der Migrationsplan verfolgt beide Zeitlinien dann getrennt.
Fähigkeiten den Schichten zuordnen hilft gegen Over-Scoping
PQC-Arbeit landet auf mehreren Schichten, und jeder Anbieter kündigt tendenziell auf der Schicht an, auf der sein Produkt lebt. Eine einfache mentale Karte dafür zu führen, welche Ankündigung zu welcher Schicht gehört, spart viel Meetingzeit.
Microsoft SymCrypt, das ML-KEM-Unterstützung hinzufügt, ist eine Tatsache auf der Ebene der Krypto-Bibliothek; ob ein konkretes Microsoft-Produkt wie SQL Server ML-KEM in seinem Handshake aushandelt, ist eine separate Entscheidung auf Produktebene. Cloudflare-Zahlen zu Client-zu-Edge-PQC liegen auf einer Ebene; Origin-zu-Cloudflare-PQC auf einer anderen. Microsofts CPM-Framework selbst trennt diese sauber in die Domänen Code, Netzwerk, Laufzeit und Speicher.
Eine CA, die ML-DSA-Zertifikate ausstellt, ist eine Schicht. Ein Server, der eines dieser Zertifikate in einem live geführten Handshake präsentiert, ist die nächste Schicht. Ein Client, der dazu einen hybriden ML-KEM-Schlüsselaustausch wählt, ist die Schicht danach. Jede Fähigkeit ist real auf der Ebene, auf der sie lebt. Die HNDL-Exposition entscheidet sich konkret daran, welcher Schlüsselaustausch zwischen Server und Client tatsächlich ausgewählt wird.
Was ein Handshake-Scan zur Planung beiträgt
Sobald ein Team Ankündigungen nach Schicht sortiert hat, ist die praktische Frage, was die eigene Infrastruktur heute tut. TLS-Handshakes zu scannen, beantwortet das für die Netzwerkebene: was der Server angeboten hat, was ausgewählt wurde und was die Zertifikatskette signiert hat. Ein Server, der ein Sectigo-Private-PQC-Zertifikat präsentiert, würde ML-DSA-44, ML-DSA-65 oder ML-DSA-87 im Signaturalgorithmus-Feld zeigen. Das Schlüsselaustauschgruppen-Feld meldet, was tatsächlich ausgehandelt wurde, was für die meisten heutigen Deployments weiterhin eine ECDH-Kurve ist.
Wiederholte Scans über eine Site-Flotte ergeben die Trajektorie: ob ein Deployment sich in Richtung hybriden PQC-Schlüsselaustauschs bewegt, stabil auf klassischem Schlüsselaustausch mit einer neu aufgelegten Signaturebene sitzt oder sich in eine andere Richtung bewegt. Dieses Bild ergänzt die Anbieterankündigungen mit Daten aus dem eigenen Stack.
Planen durch das Finanzierungsfenster
Sectigos Pressemitteilung nennt die Zahl, dass 90 Prozent der Organisationen erwarten, PQC-Initiativen in den nächsten zwölf Monaten zu finanzieren. Beschaffungsdruck, die Fristen von Google und Cloudflare für 2029, die BSI-TR-02102-Leitlinien und DORA zeigen alle in dieselbe Richtung. Mehr PQC-etikettierte Features werden durch dieses Fenster landen. Einige adressieren die Zertifikatsschicht, einige die Handshake-Schicht, einige aktualisieren die zugrunde liegenden Krypto-Bibliotheken, ohne das Aushandlungsverhalten zu verändern. Alle drei Arbeitsarten sind legitim, und ein reifes Programm umfasst alle drei.
Eine nach Schichten gegliederte Karte des eigenen Estates (welche Zertifikate Sie ausstellen, was Ihre Server aushandeln, was Ihre Clients bevorzugen) erlaubt es, jede Anbieterankündigung der richtigen Position im Plan zuzuordnen. Das ist die Prüfung, die ein PQC-Programm in gesundem Verhältnis zur tatsächlich adressierten Bedrohungsoberfläche hält und jede investierte Finanzierungseinheit leichter rechtfertigbar macht.