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 gehalten werden und diesen nie im Klartext verlassen.
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
CA-Signierschlüssel und verwaltete Endzertifikatsschlüssel sind Vault-gestützt (z. B. Securosys FIPS 140-2 Level 3); private Schlüssel verlassen den Vault niemals im Klartext.
Architektur
Zertifizierungsstellen
Eine CA wird innerhalb der Plattform erstellt, und ihr Signierschlüssel wird entweder lokal generiert oder, bei Post-Quanten- und HSM-geschützten CAs, im Vault gehalten.
| 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-4096 |
| ECC | EC-P256, EC-P384 |
| Post-Quanten (Signaturen) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybrid / Komposit | ML-DSA-65 + ECDSA-P256 |
RSA-3072 und EC-P521 werden nicht unterstützt, und es gibt keine 8192-Bit-RSA-Option. Post-Quanten- und Hybrid-CAs sind Vault-signiert (ihre Schlüssel befinden sich im Vault); klassische CAs können lokal signieren.
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)