Créer une autorité de certification PKI : architecture avant commandes

Repère pratique

Décider pourquoi la PKI existe

Énumère les usages : TLS interne, authentification de machines, signature, VPN ou code. Chaque usage implique des extensions, des durées et des processus différents. Évite une autorité universelle qui signe tout. Définis aussi qui peut demander, approuver, émettre, révoquer et auditer.

Rédige une politique courte avant l’installation : identité vérifiée, formats de noms, algorithmes, durées, renouvellement, motif de révocation et conservation des journaux. Ce document évite que les exceptions techniques deviennent la politique par défaut.

Repère pratique

Séparer la racine et l’intermédiaire

La racine est l’ancre de confiance. Elle devrait rester hors ligne, utilisée rarement pour signer une autorité intermédiaire et les listes nécessaires. L’intermédiaire émet les certificats courants. Sa compromission permet de révoquer et remplacer l’intermédiaire sans redéployer une nouvelle racine sur tous les postes.

Utilise des environnements, comptes et supports distincts. Protège les clés par des secrets robustes et, selon le niveau de risque, par un matériel dédié. Documente les personnes requises pour une opération sensible. Une copie de sauvegarde doit être chiffrée, testée et stockée séparément.

Repère pratique

Générer une clé de laboratoire sans figer de mauvaises habitudes

La commande genpkey permet de générer une clé privée. Le choix RSA ou courbes elliptiques dépend des clients, des usages et de la politique. Dans un laboratoire RSA, une taille moderne et une phrase secrète protègent le fichier au repos. Les permissions du système restent indispensables.

Ne place jamais la clé de racine sur une machine connectée en permanence. N’utilise pas cet exemple tel quel pour une production : le chemin, la source d’aléa, la protection opérateur, le journal et la sauvegarde doivent être contrôlés.

umask 077
openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:4096 \
  -aes-256-cbc -out root-ca.key.pem

Repère pratique

Définir des profils de certificat stricts

Un certificat d’autorité doit porter les contraintes CA adaptées. Un certificat serveur doit contenir les noms dans Subject Alternative Name et des usages de clé cohérents. Les clients modernes ne doivent pas dépendre du seul Common Name. Sépare les profils serveur, client, appareil et signature.

Refuse les demandes qui ajoutent des extensions non autorisées. L’autorité ne doit pas recopier aveuglément tout ce que contient une CSR. Contrôle les noms, les domaines, les adresses et l’identité du demandeur. Garde la configuration sous contrôle de version sans y stocker les clés.

Repère pratique

Publier chaîne, révocation et points de contrôle

Les clients ont besoin de la chaîne correcte : certificat final, intermédiaire et racine déjà approuvée. Publie les certificats d’autorité et les informations de révocation sur des emplacements stables. Décide entre CRL, OCSP ou les mécanismes compatibles avec ton environnement et teste le comportement quand le service de statut est indisponible.

La révocation ne fonctionne que si elle est rapide et réellement consultée. Prépare les motifs : perte de clé, départ, appareil volé, erreur d’identité ou remplacement. Mesure le délai entre la demande et la publication. Une liste jamais renouvelée donne une illusion de contrôle.

Repère pratique

Tester le cycle de vie et la catastrophe

Émets un certificat de test, déploie la chaîne, vérifie les usages, renouvelle puis révoque. Observe les journaux côté client et serveur. Teste les erreurs : nom absent, certificat expiré, chaîne incomplète, clé non correspondante et CRL périmée.

Organise enfin un exercice de perte d’intermédiaire et un exercice de restauration de la racine. Si la procédure dépend d’une personne, d’un mot de passe ou d’un lecteur introuvable, la PKI n’est pas prête. Note chaque étape et fais signer le résultat de la cérémonie de test.

• Demande et approbation tracées
• Profils séparés par usage
• Renouvellement avant expiration
• Révocation publiée et vérifiée
• Restauration testée
• Inventaire des certificats actifs

Repère pratique

Rendre l’exploitation quotidienne soutenable

Une PKI vieillit même lorsqu’aucun incident n’est visible. Surveille les expirations, la taille et la fraîcheur des listes de révocation, les échecs de publication et les certificats qui ne correspondent plus à un actif. Définis des alertes assez tôt pour renouveler sans urgence et teste-les avec un certificat de laboratoire.

Sépare le tableau de bord opérationnel de l’audit. L’exploitation a besoin de savoir quoi traiter aujourd’hui ; l’audit doit pouvoir reconstruire qui a demandé, approuvé, émis, révoqué ou modifié une configuration. Conserve des horloges synchronisées et protège les journaux contre une modification par le même compte qui administre l’autorité.