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 générées et utilisées dans un vault, HSM, KMS cloud ou cluster MPC lorsque la CA est créée avec l'un d'eux (voir Protection des clés de CA).
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) ainsi que l'enrôlement automatique Windows et la distribution Intune, 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 de CA protégées par HSM, KMS et MPC
Une CA créée avec un vault conserve sa clé de signature dans ce vault — HSM (par exemple Securosys), KMS cloud ou cluster MPC — et chaque certificat, CRL et réponse OCSP y est signé ; rien n'est exporté. Une CA créée sans vault utilise une clé logicielle stockée par la plateforme et peut être migrée. Les clés des certificats terminaux gérés sont actuellement générées et conservées dans le vault logiciel de la plateforme ; avec la permission d'export, la clé privée d'un certificat peut être téléchargée (PEM ou PKCS#12).
Alertes d'expiration et certificats à courte durée de vie
Alertes d'expiration par e-mail, Microsoft Teams, Slack et webhooks, une fois par seuil, et informations de renouvellement ACME pour que les clients renouvellent à temps alors que les durées de vie descendent vers 47 jours.
Signature de code et identité des appareils
Un service de signature de code pour SignTool, JAR, Git et cosign avec des clés de vault non exportables et des approbations, et le provisionnement d'appareils EST / CMP pour les parcs IoT et réseau.
Gouvernance
Quorum M-of-N sur la révocation et l'archivage de CA, les modifications de CA et de modèles et l'émission à haute valeur, et politiques d'accès par utilisateur, IP, pays et horaire sur l'émission et la révocation, sur tous les protocoles d'enrôlement.
Architecture
Autorités de certification
Une CA est créée à l'intérieur de la plateforme. Lorsqu'elle est créée avec un vault, sa clé de signature est générée et conservée dans ce vault (HSM, KMS cloud ou cluster MPC) et n'est jamais exportée ; sans vault, la clé est générée en logiciel et stockée par la plateforme. Les CA post-quantiques et hybrides résident toujours dans un vault. Voir Protection des clés de CA.
| 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-3072, RSA-4096, RSA-8192 (clés de CA) |
| ECC | EC-P256, EC-P384, EC-P521 (clés de CA) |
| Post-quantique (signatures) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybride / composite | ML-DSA-65 + ECDSA-P256 |
RSA-2048, RSA-4096, EC-P256 et EC-P384 sont disponibles pour une clé de CA dans tous les vaults. RSA-3072, RSA-8192 et EC-P521 dépendent de l'endroit où la clé de CA est conservée :
- Software Vault et Securosys Primus : les trois.
- Azure Key Vault :
RSA-3072etEC-P521. Azure ne va pas au-delà de RSA 4096 bits. - AWS KMS :
EC-P521. Les clés RSA de CA ne sont pas conservées dans AWS KMS, car la plateforme crée les clés RSA AWS pour le chiffrement. - Google Cloud KMS : aucune des trois. Google ne propose pas la courbe P-521, et la plateforme crée les clés RSA Google pour le chiffrement.
- Sans vault : les trois, sous forme de clé logicielle stockée avec la CA.
La page de création de CA ne liste que les tailles que le vault sélectionné peut conserver. Une CA P-521 signe avec ECDSA et SHA-512. Les certificats émis par la plateforme avec une clé générée côté serveur utilisent RSA-2048, RSA-3072, RSA-4096, EC-P256 ou EC-P384 ; RSA-8192 et EC-P521 sont réservées aux clés de CA.
Les CA post-quantiques et hybrides sont signées par le vault (leurs clés résident dans le vault) ; les CA classiques sont signées par le vault lorsqu'elles sont créées avec un vault, sinon elles signent avec une clé logicielle.
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.
En plus des permissions, la gouvernance PKI lie une approbation par quorum M-of-N et des politiques d'accès (utilisateur, IP, pays, horaire) aux CA et aux modèles de certificats.
Explorer par module
Gestion des CA
CA racines, intermédiaires et externes, et le cycle de vie complet des CA
Protection des clés de CA
Clés de CA dans un HSM, un KMS cloud ou un cluster MPC
Émetteurs
Connecteurs de CA externes, cloud et internes
Protocoles d'enrôlement
ACME, EST, SCEP, CMP, cert-manager, KMIP
Enrôlement automatique Windows
Enrôlement et renouvellement par stratégie de groupe
Intune et MDM
Distribution SCEP et PKCS aux appareils gérés
Certificats à courte durée de vie
ACME ARI et préparation aux 47 jours
Identité des appareils
Provisionnement EST et CMP des parcs
Déploiement
Pousser les certificats vers F5, Fortinet, Azure, Entra et plus
Renouvellement et alertes
Renouvellement, redéploiement et alertes d'expiration
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
Signature de code
SignTool, JAR, Git et cosign avec des clés de vault
Gouvernance PKI
Quorum M-of-N et politiques d'accès sur les CA
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)