DuoKey PKI/SSL – Überblick
Eine vollständige Plattform für Zertifizierungsstellen und den Zertifikatslebenszyklus, integriert in DuoKey Cockpit, mit Vault-/HSM-geschützten Signierschlüsseln.
Was ist DuoKey PKI/SSL?
DuoKey PKI/SSL ist eine vollständige Public-Key-Infrastruktur, die in DuoKey Cockpit integriert ist. Sie ermöglicht es einer Organisation, eigene Zertifizierungsstellen zu betreiben (Root und Intermediate) oder externe/öffentliche CAs vorzuschalten, und dann Zertifikate im gesamten Bestand zu ausstellen, bereitzustellen, überwachen und widerrufen — wobei die CA-Signierschlüssel in einem Vault, HSM, Cloud-KMS oder MPC-Cluster erzeugt und verwendet werden, wenn die CA mit einem solchen erstellt wird (siehe CA Key Protection).
Im Gegensatz zu einem einfachen SSL-Antragsformular deckt die Plattform den gesamten Zertifikatslebenszyklus ab: eine CA-Hierarchie, einen Antrags- und Genehmigungsworkflow, die gängigen Enrollment-Protokolle (ACME, EST, SCEP, CMP, Kubernetes cert-manager, KMIP), einen Katalog externer CA-Aussteller, Bereitstellungs-Konnektoren zu Netzwerkgeräten und Cloud-Diensten, OCSP-Responder und CRL-Verteilung sowie sowohl klassische als auch Post-Quanten-Schlüsselalgorithmen.
Wo ein Konzept öffentlicher CAs (etwa die Validierungsstufen DV/OV/EV) auf eine privat betriebene CA nicht zutrifft, wird es in dieser Plattform bewusst weggelassen.
Kernfunktionen
CA-Hierarchie & Lebenszyklus
Root-, Intermediate- und importierte externe CAs, mit Suspendieren/Reaktivieren, einfachem und kaskadierendem Widerruf, Archivierung und einer schreibgeschützten Vorschau der Lebenszyklus-Auswirkungen vor jeder kaskadierenden Aktion.
Zertifikatslebenszyklus
Ausstellung unter einer CA, ein CSR-Genehmigungsworkflow (Antrag → genehmigen/ablehnen → ausstellen), Erneuerung, Widerruf mit RFC-5280-Gründen und wiederverwendbare Zertifikatsvorlagen.
Standard-Enrollment-Protokolle
ACME (RFC 8555), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager und ein KMIP-2.1-Server-Endpunkt.
Externe CA-Aussteller
Vorschaltung öffentlicher und Cloud-CAs: Let's Encrypt, AWS Private CA, Azure Key Vault CA, Google Cloud CAS, Sectigo, DigiCert, QuoVadis, Cloudflare und weitere.
Bereitstellungsautomatisierung
Zertifikate direkt auf F5 BIG-IP, Fortinet FortiGate, Azure App Service, Entra ID sowie Apache / Nginx / IIS / JKS / Windows CAPI übertragen — mit Validierung und Rollback.
Validierung & Widerruf
OCSP-Responder je CA sowie CRL-Erzeugung und -Verteilung, sodass vertrauende Parteien den Zertifikatsstatus in Echtzeit prüfen können.
Post-Quanten-bereit
Ausstellung mit NIST-PQC-Signaturalgorithmen (ML-DSA, SLH-DSA) und einem hybriden ML-DSA-65 + ECDSA-P256-Komposit, neben klassischem RSA und ECC.
Discovery & Compliance
Netzwerk- und agentenbasiertes TLS-/Zertifikats-Scanning, Import entdeckter Zertifikate, zertifikatsbezogenes SSL/TLS-Audit und Compliance-Bewertung (Mozilla / NIST / PCI DSS).
HSM-geschützte Schlüssel
Eine mit einem Vault erstellte CA behält ihren Signierschlüssel in diesem Vault — HSM (z. B. Securosys), Cloud-KMS oder MPC-Cluster — und jedes Zertifikat, jede CRL und jede OCSP-Antwort wird dort signiert; nichts wird exportiert. Eine ohne Vault erstellte CA verwendet einen von der Plattform gespeicherten Software-Schlüssel und kann migriert werden. Verwaltete Endzertifikatsschlüssel werden derzeit im Software-Vault der Plattform erzeugt und gehalten; mit der Export-Berechtigung kann der private Schlüssel eines Zertifikats heruntergeladen werden (PEM oder PKCS#12).
Architektur
Zertifizierungsstellen
Eine CA wird innerhalb der Plattform erstellt. Wird sie mit einem Vault erstellt, wird ihr Signierschlüssel in diesem Vault (HSM, Cloud-KMS oder MPC-Cluster) erzeugt und gehalten und nie exportiert; ohne Vault wird der Schlüssel in Software erzeugt und von der Plattform gespeichert. Post-Quanten- und Hybrid-CAs sind immer Vault-resident. Siehe CA Key Protection.
| CA-Typ | Wie sie erstellt wird |
|---|---|
| Root-CA | Selbstsignierter Vertrauensanker |
| Intermediate-/Issuing-CA | Signiert durch eine übergeordnete Root- oder Intermediate-CA; bei PQC-/Hybrid-Ketten wird die Algorithmus-Kompatibilität mit der übergeordneten CA erzwungen |
| Externe CA | Aus einer bestehenden PKI importiert, damit die Plattform sie verfolgen und verwalten kann |
Jede CA unterstützt einen vollständigen Lebenszyklus: suspend (RFC 5280 certificateHold) und reactivate, einfaches revoke und kaskadierenden Widerruf (der auch Sub-CAs und ausgestellte Zertifikate widerruft) sowie archive / unarchive (sobald die CA keine Zertifikate mehr ausstellt). Vor jeder kaskadierenden Aktion können Sie eine Vorschau der Lebenszyklus-Auswirkungen anfordern, die den Wirkungsbereich aufzeigt. Jede CA kann ihre Kette, eine CRL und einen OCSP-Responder veröffentlichen.
Zertifikatstypen und Schlüsselalgorithmen
| Zertifikatstyp | Typische Extended Key Usage |
|---|---|
| CA | Zertifikatssignierung (Roots / Intermediates) |
| Server (TLS/SSL) | ServerAuth |
| Client (mTLS) | ClientAuth |
| Code-Signierung | CodeSigning |
| E-Mail (S/MIME) | EmailProtection |
Subject Alternative Names können DNS, IP, E-Mail oder URI sein, einschließlich Wildcard-DNS-Einträgen (zum Beispiel *.example.com). Verfügbare Key Usages und Extended Key Usages folgen dem RFC-5280-Satz (ServerAuth, ClientAuth, CodeSigning, EmailProtection, TimeStamping, OcspSigning).
| Familie | Unterstützte Schlüsselalgorithmen |
|---|---|
| RSA | RSA-2048, RSA-3072, RSA-4096, RSA-8192 (CA-Schlüssel) |
| ECC | EC-P256, EC-P384, EC-P521 (CA-Schlüssel) |
| Post-Quanten (Signaturen) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybrid / Komposit | ML-DSA-65 + ECDSA-P256 |
RSA-2048, RSA-4096, EC-P256 und EC-P384 stehen für einen CA-Schlüssel in jedem Vault zur Verfügung. Ob RSA-3072, RSA-8192 und EC-P521 verfügbar sind, hängt davon ab, wo der CA-Schlüssel gespeichert ist:
- Software Vault und Securosys Primus: alle drei.
- Azure Key Vault:
RSA-3072undEC-P521. Azure unterstützt RSA nur bis 4096 Bit. - AWS KMS:
EC-P521. RSA-CA-Schlüssel werden nicht in AWS KMS gespeichert, da die Plattform RSA-Schlüssel in AWS für die Verschlüsselung erstellt. - Google Cloud KMS: keine der drei. Google bietet keine P-521-Kurve, und die Plattform erstellt RSA-Schlüssel in Google für die Verschlüsselung.
- Kein Vault: alle drei, als Software-Schlüssel, der zusammen mit der CA gespeichert wird.
Die Seite zur CA-Erstellung listet nur die Größen auf, die der ausgewählte Vault speichern kann. Eine P-521-CA signiert mit ECDSA und SHA-512. Zertifikate, die die Plattform mit einem serverseitig erzeugten Schlüssel ausstellt, verwenden RSA-2048, RSA-3072, RSA-4096, EC-P256 oder EC-P384; RSA-8192 und EC-P521 sind ausschließlich CA-Schlüsselgrößen.
Post-Quanten- und Hybrid-CAs sind Vault-signiert (ihre Schlüssel befinden sich im Vault); klassische CAs werden im Vault signiert, wenn sie mit einem Vault erstellt wurden, andernfalls mit einem Software-Schlüssel.
Enrollment-Protokolle
Geräte und Workloads können sich direkt über das Protokoll registrieren, das sie bereits sprechen — jedes verfügt über einen öffentlichen Protokoll-Endpunkt sowie eine Admin-Konfiguration im Cockpit.
| Protokoll | Standard | Typische Verwendung |
|---|---|---|
| ACME | RFC 8555 | Automatisierte Webserver-Zertifikate (Clients im Let's-Encrypt-Stil, cert-manager) |
| EST | RFC 7030 | Enrollment over Secure Transport für Geräte und Gateways |
| SCEP | RFC 8894 | Netzwerkgeräte und MDM-verwaltete Endpunkte |
| CMP | RFC 4210 / 9483 | Zertifikatsverwaltung für industrielle PKIs und Betreiber-PKIs |
| cert-manager | Kubernetes | Externer Issuer für Kubernetes-Workloads |
| KMIP | OASIS KMIP 2.1 | Cockpit agiert als KMIP-Server für Schlüssel-/Zertifikatsobjekte |
Externe CA-Aussteller
Anstelle von (oder zusätzlich zu) eigenen CAs kann die Plattform externe Zertifizierungsstellen über Issuer-Konnektoren ansteuern, sodass Anträge, Erneuerungen und Widerrufe über eine einzige Konsole laufen.
| Aussteller | Backend |
|---|---|
| Let's Encrypt | Öffentliche ACME-CA (inkl. Verarbeitung der http-01-Challenge) |
| AWS Private CA | AWS ACM Private CA |
| Azure Key Vault CA | Azure Key Vault Zertifikats-CA |
| Google Cloud CAS | Google Certificate Authority Service |
| Sectigo | Kommerzielle CA |
| DigiCert / QuoVadis | DigiCert CertCentral (und Tochtergesellschaft QuoVadis) |
| Cloudflare | Origin-/Edge-CA |
| Volkswagen Group PKI | PPCS mTLS Enterprise-PKI |
| Interne CA | Eine lokal betriebene, Vault-gestützte CA |
Jeder Aussteller unterstützt Verbindungstest, Ausstellen, Erneuern, Widerrufen und (bei ACME) die Kontoregistrierung.
Bereitstellungsziele
Ausgestellte Zertifikate können direkt dorthin übertragen werden, wo sie TLS terminieren, mit Job-basierter Validierung und Rollback.
| Ziel | Hinweise |
|---|---|
| F5 BIG-IP | iControl REST — Bereitstellung von Zertifikat+Schlüssel oder nur Zertifikat, mit Rollback |
| Fortinet FortiGate | Bereitstellung und Rollback |
| Azure App Service | Zertifikate an App Services binden |
| Entra ID | App Proxy und App-Registrierung |
| Apache · Nginx · IIS · JKS · Windows CAPI | Generische Bereitstellungsziele |
| ServiceNow CMDB | Inventar-/Ablauf-Synchronisierung (kein TLS-Terminierungsziel) |
Zugriffssteuerung
PKI-Vorgänge werden durch feingranulare, mandantenbezogene rollenbasierte Berechtigungen abgesichert, die pro Aktion geprüft werden. Separate Berechtigungen decken die Verwaltung von Zertifizierungsstellen, das Ausstellen und Widerrufen von Zertifikaten, das Genehmigen oder Ablehnen von Anträgen sowie die Verwaltung von Widerrufsdaten ab — so lässt sich eine saubere Aufgabentrennung durchsetzen.
Da Berechtigungen mandantenbezogen sind, sieht und verwaltet jede Organisation stets nur ihre eigenen CAs und Zertifikate.
Nach Modul erkunden
CA-Verwaltung
Root-, Intermediate- und externe CAs sowie der vollständige CA-Lebenszyklus
Aussteller
Externe, Cloud- und interne CA-Konnektoren
Enrollment-Protokolle
ACME, EST, SCEP, CMP, cert-manager, KMIP
Bereitstellung
Zertifikate auf F5, Fortinet, Azure, Entra und weitere übertragen
Widerruf (OCSP & CRL)
Zertifikatsstatus veröffentlichen und prüfen
Post-Quanten-PKI
ML-DSA, SLH-DSA und Hybrid-Zertifikate
Discovery & Compliance
TLS im gesamten Bestand scannen, prüfen und bewerten
Voraussetzungen
Voraussetzungen
- Aktives DuoKey-Cockpit-Konto mit PKI-Zugriff
- Die relevanten PKI-Berechtigungen (oder eine Admin-Rolle)
- Ein für CA-Signierschlüssel konfigurierter Vault
- Für externe Aussteller: Anmeldedaten für die Ziel-CA (API-Schlüssel, Konto oder Cloud-Rolle)