Prise en main
Rôles et permissions, algorithmes et types de certificats pris en charge, et le cycle de vie du certificat dans DuoKey PKI.
Vue d'ensemble
Démarrer avec DuoKey PKI implique de comprendre trois choses : les rôles et permissions qui contrôlent les actions PKI, les algorithmes et types de certificats pris en charge par la plateforme, et le cycle de vie de la demande à l'émission. Cette page couvre les trois ; le guide Créer un certificat vous accompagne ensuite dans l'émission de votre premier certificat.
Prérequis
- Un compte DuoKey Cockpit actif
- Les permissions PKI concernées (ou un rôle administrateur)
- Un vault configuré pour les clés de signature des CA
- Une CA depuis laquelle émettre (créez-en une, ou connectez un émetteur externe)
Rôles et permissions
Les actions PKI sont autorisées par des permissions basées sur les rôles, fines et cantonnées au tenant. Une séparation des tâches typique répartit les responsabilités ainsi :
| Responsabilité | Rôle typique |
|---|---|
| Demander un certificat | Demandeur de certificat |
| Approuver / rejeter les demandes | Approbateur de certificat |
| Gérer les autorités de certification | Administrateur de CA |
| Révoquer des certificats | Opérateur de certificat |
| Gérer les données de révocation (CRL) | Administrateur de CA |
| Visibilité en lecture seule | Auditeur / observateur |
Différentes opérations peuvent nécessiter des permissions différentes. Si vous rencontrez une erreur de permission, vérifiez quelle permission PKI l'action requiert et demandez à votre administrateur de l'accorder.
Informations requises
Avant de créer un certificat, rassemblez les détails du sujet :
| Champ | Exemple | Description |
|---|---|---|
| Nom commun (CN) | www.example.com | Identité principale (FQDN pour le TLS ; peut être un caractère générique) |
| Organisation (O) | Acme Corporation | Nom légal de l'organisation |
| Unité organisationnelle (OU) | IT | Département, facultatif |
| Pays (C) | US, CH, GB | Code pays à deux lettres |
| État/Province (ST) | Vaud | Nom complet de l'état ou de la province |
| Ville/Localité (L) | Lausanne | Nom de la ville |
| Noms alternatifs du sujet | api.example.com, 10.0.0.1 | Identités DNS / IP / e-mail / URI supplémentaires |
Types de certificats
La plateforme émet des certificats pour des usages distincts, chacun associé à l'usage étendu de clé approprié :
| Type | Usage | Usage étendu de clé |
|---|---|---|
| Serveur (TLS/SSL) | Services HTTPS et à terminaison TLS | ServerAuth |
| Client (mTLS) | Authentification client mutual-TLS | ClientAuth |
| Signature de code | Signature de logiciels et d'artefacts | CodeSigning |
| E-mail (S/MIME) | Signature et chiffrement des e-mails | EmailProtection |
| CA | Certificats de signature racine et intermédiaires | Signature de certificats |
Les noms alternatifs du sujet peuvent être de type DNS, IP, e-mail ou URI. Pour sécuriser tous les sous-domaines de premier niveau, utilisez un nom commun générique tel que *.example.com, avec en option des entrées SAN supplémentaires pour des hôtes spécifiques.
Algorithmes de clés
Choisissez l'algorithme de clé au moment de la demande. Des options classiques et post-quantiques sont disponibles :
| Algorithme | Catégorie | Quand l'utiliser |
|---|---|---|
RSA-2048 | Classique (RSA) | Usage général, largement compatible |
RSA-4096 | Classique (RSA) | RSA à assurance renforcée |
EC-P256 | Classique (ECC) | Choix par défaut efficace pour le TLS moderne |
EC-P384 | Classique (ECC) | ECC à assurance renforcée |
ML-DSA-44 / 65 / 87 | Post-quantique (FIPS 204) | Signatures résistantes au quantique |
SLH-DSA-128F / 128S | Post-quantique (FIPS 205) | Signatures résistantes au quantique à base de hachage |
ML-DSA-65 + ECDSA-P256 | Hybride / composite | Résistance quantique et assurance classique réunies dans un même certificat |
Il n'existe pas d'option RSA-3072, EC-P521 ou RSA 8192 bits. Un choix d'algorithme non reconnu retombe sur EC-P256 : sélectionnez donc explicitement un algorithme dans la liste ci-dessus. Les clés post-quantiques et hybrides résident dans le vault (la CA de signature doit être adossée à un vault).
Le cycle de vie du certificat
Créer la demande
Un demandeur soumet une demande de certificat avec les détails du sujet, le type, l'algorithme de clé et les SAN. La demande passe à l'état En attente.
Approuver ou rejeter
Un approbateur examine la demande et l'approuve ou la rejette. Des commentaires sont enregistrés pour la piste d'audit.
Émettre
Lors de l'émission, la CA signe le certificat. Pour les clés gérées, la paire de clés est générée et conservée dans le vault ; pour une clé fournie via CSR, la clé publique soumise est certifiée. La demande passe à l'état Émis.
Exploiter
Le certificat actif peut être consulté, exporté (parties publiques), déployé sur une cible, et surveillé via OCSP / CRL.
Renouveler ou révoquer
Renouvelez avant expiration (réémission depuis la demande ou via l'émetteur), ou révoquez avec un motif RFC 5280 — ce qui se reflète alors dans la CRL et les réponses OCSP de la CA.
Au-delà du flux de demande manuel, les équipements et charges de travail peuvent s'enrôler automatiquement via ACME, EST, SCEP, CMP, Kubernetes cert-manager ou KMIP — voir la Vue d'ensemble.