Vue d'ensemble de DuoKey PKI/SSL
Une plateforme complète d'autorité de certification et de cycle de vie des certificats intégrée à DuoKey Cockpit, avec des clés de signature protégées par vault/HSM.
Qu'est-ce que DuoKey PKI/SSL ?
DuoKey PKI/SSL est une infrastructure à clés publiques complète intégrée à DuoKey Cockpit. Elle permet à une organisation de faire fonctionner ses propres autorités de certification (racine et intermédiaires), ou de piloter des CA externes / publiques, puis d'émettre, déployer, surveiller et révoquer des certificats sur l'ensemble de son parc — avec les clés de signature des CA conservées dans un vault / HSM, sans jamais en sortir en clair.
Contrairement à un simple formulaire de demande SSL, la plateforme couvre l'intégralité du cycle de vie du certificat : une hiérarchie de CA, un flux de demande et d'approbation, les protocoles d'enrôlement standards (ACME, EST, SCEP, CMP, Kubernetes cert-manager, KMIP), un catalogue d'émetteurs de CA externes, des connecteurs de déploiement vers des équipements réseau et des services cloud, des répondeurs OCSP et une distribution de CRL, ainsi que des algorithmes de clés classiques et post-quantiques.
Lorsqu'un concept propre aux CA publiques (comme les niveaux de validation DV/OV/EV) ne s'applique pas à une CA à usage privé, il est volontairement omis de cette plateforme.
Fonctionnalités principales
Hiérarchie et cycle de vie des CA
CA racines, intermédiaires et externes importées, avec suspension / réactivation, révocation simple et en cascade, archivage, et un aperçu d'impact sur le cycle de vie en lecture seule avant toute action en cascade.
Cycle de vie des certificats
Émission sous une CA, un flux d'approbation de CSR (demande → approbation/rejet → émission), renouvellement, révocation avec les motifs RFC 5280, et des modèles de certificats réutilisables.
Protocoles d'enrôlement standards
ACME (RFC 8555), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), cert-manager Kubernetes, et un point de terminaison serveur KMIP 2.1.
Émetteurs de CA externes
Pilotez des CA publiques et cloud : Let's Encrypt, AWS Private CA, Azure Key Vault CA, Google Cloud CAS, Sectigo, DigiCert, QuoVadis, Cloudflare et bien d'autres.
Automatisation du déploiement
Poussez les certificats vers F5 BIG-IP, Fortinet FortiGate, Azure App Service, Entra ID, et Apache / Nginx / IIS / JKS / Windows CAPI — avec validation et retour en arrière (rollback).
Validation et révocation
Répondeurs OCSP par CA et génération / distribution de CRL, afin que les parties de confiance puissent vérifier le statut d'un certificat en temps réel.
Prêt pour le post-quantique
Émettez avec les algorithmes de signature post-quantiques du NIST (ML-DSA, SLH-DSA) et un composite hybride ML-DSA-65 + ECDSA-P256, aux côtés du RSA et de l'ECC classiques.
Découverte et conformité
Scan TLS/certificats réseau et par agent, import des certificats découverts, audit SSL/TLS par certificat et évaluation de conformité (Mozilla / NIST / PCI DSS).
Clés protégées par HSM
Les clés de signature des CA et les clés terminales gérées sont adossées à un vault (par exemple Securosys FIPS 140-2 Level 3) ; les clés privées ne quittent jamais le vault en clair.
Architecture
Autorités de certification
Une CA est créée à l'intérieur de la plateforme et sa clé de signature est générée localement ou, pour les CA post-quantiques et protégées par HSM, conservée dans le vault.
| Type de CA | Comment elle est créée |
|---|---|
| CA racine | Ancre de confiance auto-signée |
| CA intermédiaire / émettrice | Signée par une CA racine ou intermédiaire parente ; la compatibilité d'algorithme avec le parent est imposée pour les chaînes PQC / hybrides |
| CA externe | Importée depuis une PKI existante afin que la plateforme puisse la suivre et la gérer |
Chaque CA prend en charge un cycle de vie complet : suspend (certificateHold RFC 5280) et reactivate, revoke simple et révocation en cascade (qui révoque également les sous-CA et les certificats émis), et archive / unarchive (une fois que la CA a cessé d'émettre). Avant toute action en cascade, vous pouvez demander un aperçu d'impact sur le cycle de vie qui indique le rayon d'action. Chaque CA peut publier sa chaîne, une CRL, et un répondeur OCSP.
Types de certificats et algorithmes de clés
| Type de certificat | Usage étendu de clé typique |
|---|---|
| CA | Signature de certificats (racines / intermédiaires) |
| Serveur (TLS/SSL) | ServerAuth |
| Client (mTLS) | ClientAuth |
| Signature de code | CodeSigning |
| E-mail (S/MIME) | EmailProtection |
Les noms alternatifs du sujet peuvent être de type DNS, IP, e-mail ou URI, y compris des entrées DNS génériques (par exemple *.example.com). Les usages de clé et usages étendus de clé disponibles suivent l'ensemble RFC 5280 (ServerAuth, ClientAuth, CodeSigning, EmailProtection, TimeStamping, OcspSigning).
| Famille | Algorithmes de clés pris en charge |
|---|---|
| RSA | RSA-2048, RSA-4096 |
| ECC | EC-P256, EC-P384 |
| Post-quantique (signatures) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybride / composite | ML-DSA-65 + ECDSA-P256 |
RSA-3072 et EC-P521 ne sont pas pris en charge, et il n'existe pas d'option RSA 8192 bits. Les CA post-quantiques et hybrides sont signées par le vault (leurs clés résident dans le vault) ; les CA classiques peuvent signer localement.
Protocoles d'enrôlement
Les équipements et charges de travail peuvent s'enrôler directement en utilisant le protocole qu'ils parlent déjà — chacun dispose d'un point de terminaison de protocole public ainsi que d'une configuration d'administration dans le Cockpit.
| Protocole | Standard | Usage typique |
|---|---|---|
| ACME | RFC 8555 | Certificats de serveur web automatisés (clients de type Let's-Encrypt, cert-manager) |
| EST | RFC 7030 | Enrôlement sur transport sécurisé pour équipements et passerelles |
| SCEP | RFC 8894 | Équipements réseau et points de terminaison gérés par MDM |
| CMP | RFC 4210 / 9483 | Gestion de certificats pour les PKI industrielles / opérateurs |
| cert-manager | Kubernetes | Émetteur externe pour les charges de travail Kubernetes |
| KMIP | OASIS KMIP 2.1 | Le Cockpit agit comme serveur KMIP pour les objets clé/certificat |
Émetteurs de CA externes
Au lieu de (ou en complément de) vos propres CA, la plateforme peut piloter des autorités de certification externes via des connecteurs d'émetteurs, de sorte que les demandes, renouvellements et révocations passent par une seule console.
| Émetteur | Backend |
|---|---|
| Let's Encrypt | CA ACME publique (avec gestion du challenge http-01) |
| AWS Private CA | AWS ACM Private CA |
| Azure Key Vault CA | CA de certificats Azure Key Vault |
| Google Cloud CAS | Google Certificate Authority Service |
| Sectigo | CA commerciale |
| DigiCert / QuoVadis | DigiCert CertCentral (et sa filiale QuoVadis) |
| Cloudflare | CA d'origine / de périphérie |
| Volkswagen Group PKI | PKI d'entreprise mTLS PPCS |
| Internal CA | Une CA exploitée localement et adossée à un vault |
Chaque émetteur prend en charge le test de connexion, l'émission, le renouvellement, la révocation et (pour ACME) l'enregistrement de compte.
Cibles de déploiement
Les certificats émis peuvent être poussés directement là où ils terminent le TLS, avec validation et retour en arrière (rollback) par tâche.
| Cible | Notes |
|---|---|
| F5 BIG-IP | iControl REST — déploie le certificat+clé ou le certificat seul, avec rollback |
| Fortinet FortiGate | Déploiement et rollback |
| Azure App Service | Lie les certificats aux app services |
| Entra ID | App Proxy et App Registration |
| Apache · Nginx · IIS · JKS · Windows CAPI | Cibles de déploiement génériques |
| ServiceNow CMDB | Synchronisation d'inventaire / d'expiration (pas une cible de terminaison TLS) |
Contrôle d'accès
Les opérations PKI sont soumises à des permissions basées sur les rôles, fines et cantonnées au tenant, vérifiées à chaque action. Des permissions distinctes couvrent la gestion des autorités de certification, l'émission et la révocation des certificats, l'approbation ou le rejet des demandes, et la gestion des données de révocation — ce qui permet d'imposer une séparation nette des tâches.
Les permissions étant cantonnées au tenant, chaque organisation ne voit et ne gère jamais que ses propres CA et certificats.
Explorer par module
Gestion des CA
CA racines, intermédiaires et externes, et le cycle de vie complet des CA
Émetteurs
Connecteurs de CA externes, cloud et internes
Protocoles d'enrôlement
ACME, EST, SCEP, CMP, cert-manager, KMIP
Déploiement
Pousser les certificats vers F5, Fortinet, Azure, Entra et plus
Révocation (OCSP & CRL)
Publier et vérifier le statut des certificats
PKI post-quantique
ML-DSA, SLH-DSA et certificats hybrides
Découverte et conformité
Scanner, auditer et noter le TLS sur l'ensemble du parc
Prérequis
Prérequis
- Un compte DuoKey Cockpit actif avec accès à la PKI
- Les permissions PKI concernées (ou un rôle administrateur)
- Un vault configuré pour les clés de signature des CA
- Pour les émetteurs externes : les identifiants de la CA cible (clé API, compte ou rôle cloud)