AD CS : comment renouveler les certificats d’une autorité racine et intermédiaire ?

I. Présentation

L’expiration des certificats d’une autorité de certification (CA) peut provoquer des dysfonctionnements majeurs, allant jusqu’à bloquer la délivrance de nouveaux certificats, et empêcher le renouvellement de certificats existants.

Le renouvellement périodique de ces certificats est donc essentiel pour garantir la continuité du service et éviter toute interruption. Cette opération, bien qu’elle fasse partie des tâches de maintenance régulières d’une infrastructure PKI, reste une intervention sensible présentant un risque élevé.

Dans cet article, nous allons voir comment procéder au renouvellement du certificat racine d’une autorité de certification AD CS dans différents scénarios, tout en limitant les risques associés.

---

Envie d'apprendre à installer et configurer une CA avec AD CS ? Retrouvez notre cours complet :

• Maîtrisez l’Autorité de certification avec AD CS sous Windows Server

II. Pourquoi renouveler les certificats d'autorité ?

Comme tout composant d’une infrastructure à clés publiques (PKI), les serveurs d’autorité de certification (CA) possèdent eux aussi leurs propres certificats.

Ces certificats leur permettent de signer et délivrer d’autres certificats au nom d’une autorité de confiance, garantissant ainsi la sécurité et l’intégrité du processus.

Par défaut, la durée de validité d’un certificat d'une CA est de 5 ans. Certaines entreprises prolongent cette durée jusqu’à 10 ans lorsqu’il s’agit d’une autorité racine hébergée sur un serveur hors ligne (offline), donc moins exposée aux risques de compromission.

Il est possible de vérifier la date d’expiration directement depuis les propriétés du certificat.

À l’approche de cette date, on peut observer des échecs dans les journaux d’événements ou dans l’onglet Échecs de publication de la console, indiquant que la validité du certificat arrive à son terme ou est très courte, ainsi que les certificats ayant une date supérieure à la date d'expiration.

Si le certificat d’autorité n’est pas renouvelé à temps, le service de certification peut s’interrompre et empêcher toute délivrance de nouveaux certificats.

D’autres raisons que la simple expiration peuvent justifier un renouvellement des clés de certificat, par exemple en cas de compromission des clés privées, de modification de la longueur de clé, ou encore lors d’un changement d’algorithme de chiffrement, comme le passage du RSA vers l’ECC (Elliptic Curve Cryptography).

III. Renouvellement de certificat d'autorité

Dans cette section, nous allons aborder les cas les plus courants rencontrés en entreprise :

• Le renouvellement d’une autorité racine seule
• Le renouvellement d’une autorité intermédiaire en ligne
• Enfin, celui d’une autorité intermédiaire hors ligne (offline).

La difficulté principale de cette opération ne réside pas tant dans la partie technique que dans la planification et la préparation du déploiement. Avant toute action, il est impératif de vérifier les certificats déjà émis : en cas de renouvellement, l’ancien certificat d’autorité reste valide et utilisable tant qu’il n’a pas expiré ou été supprimé. Le renouvellement n’écrase donc pas l’ancien certificat.

Cependant, si certains certificats ont été délivrés manuellement ou possèdent une date d’expiration alignée sur celle de l’autorité, il sera nécessaire de les renouveler également pour anticiper les changements.

Un inventaire complet des certificats émis est donc fortement recommandé avant d’engager la procédure.

Avertissement

Les opérations décrites dans cet article doivent être testées en environnement de laboratoire ou de pré-production avant toute mise en œuvre en production. Il est aussi important de sauvegarder votre serveur de certificats avant toute opération de ce type, un plan de restauration devra aussi être joué et validé.

A. Autorité racine et intermédiaire en ligne

Dans le cas d’une autorité racine à un ou deux niveaux, hébergée sur des serveurs en ligne et intégrée au domaine, la procédure de renouvellement reste relativement simple. Dans notre exemple, le serveur d’autorité racine se nomme S-ROOTCA et l'intermédiaire SUBCA-1.

Une fois connecté sur votre serveur d’autorité racine en ligne, assurez-vous que le service est démarré.

Note : pour les entreprises ayant configuré leur autorité de certification à l’aide du fichier CAPolicy.inf, il sera possible de modifier ce fichier afin de prolonger la durée du certificat racine ou de forcer certains paramètres. Si le fichier n’est pas présent dans le dossier C:\Windows, cela signifie qu’il n’a pas été utilisé lors de l’installation.

Depuis la console Autorité de certification, effectuez un clic droit sur le nom de votre autorité, puis sélectionnez "Toutes les tâches", et l'action "Renouveler le certificat d’autorité de certification".

Il est important de réaliser cette opération directement depuis le serveur concerné. En effet, si vous tentez de le faire à distance, l’option ne s’affichera pas, car le nouveau certificat doit être inscrit dans le magasin local du serveur et enregistré dans le répertoire par défaut sur le disque local.

Validez ensuite le message d’avertissement indiquant que le service de certification sera temporairement arrêté le temps du renouvellement.

 Une fenêtre s’ouvre ensuite, vous invitant à choisir si vous souhaitez générer une nouvelle clé de signature ou conserver l’ancienne.

Dans notre cas, nous avons choisi "Non", pour des raisons de simplicité (comme expliqué dans la capture ci-dessous). La génération d’une nouvelle clé n’est généralement nécessaire qu’en cas de compromission ou de changement d’algorithme (explication plus bas).

B. Conserver ou générer une nouvelle clé ?

Le choix dépend avant tout de la politique de sécurité définie par le RSSI, mais également de considérations techniques. Renouveler les clés, pour les personnes maîtrisant le sujet ou dans les grands environnements, permet de repartir sur de bonnes bases de sécurité.

Comment ça marche ?

Selon Microsoft, générer une nouvelle paire de clés est recommandé si la clé actuelle est jugée vulnérable, compromise ou trop ancienne. Ce processus entraîne la création d’un nouveau certificat d’autorité, la génération d’une nouvelle demande de certificat (CSR), ainsi que la mise à jour des points de publication tels que les CRL, AIA, et les certificats croisés.

Un nouvel identifiant de clé de sujet (calculé à partir du hachage de la clé publique) est alors attribué, ce qui modifie la chaîne de confiance utilisée par le moteur de chaînage de certificats (CCE).

Dans ce scénario, les certificats précédemment émis restent liés à l’ancien certificat de l’autorité, tandis que les nouveaux certificats sont chaînés vers le nouveau. Pour maintenir une continuité, un certificat croisé (cross-cert) est automatiquement généré : la nouvelle autorité est signée par l’ancienne clé privée, créant un certificat avec un suffixe du type (0) ou (0-1).

À l’inverse, conserver la clé existante simplifie le processus si vous ne faites pas de grands changements, ajouter/suppression de rôles d'enregistrements / répondeur en ligne OCSP, etc… car tous les certificats déjà émis restent valides, chaînés automatiquement vers la nouvelle version du certificat CA. Cette approche reste pertinente tant que la clé privée est toujours considérée comme fiable.

En résumé, si votre objectif est simplement de renouveler un certificat expiré, sans modifier la longueur de clé ni l’algorithme, conserver la clé existante peut être un choix simple et suffisant.

En revanche, générer une nouvelle clé sera l’occasion de se réaligner sur les standards de sécurité actuels, notamment si les anciennes clés ne sont plus conformes ou jugées obsolètes. Ci-joint un article de Microsoft sur le sujet.

C. Déploiement de la nouvelle clé

Nous poursuivons les actions après cette courte parenthèse. En attendant quelques secondes, le nouveau certificat d’autorité est généré et le service de certification redémarre automatiquement. Vous pouvez ensuite vérifier la présence du nouveau certificat dans la console : il apparaîtra avec un indice incrémental (dans notre cas, n°1) pour le distinguer de l’ancien.

Si vous cliquez sur plus d'informations, vous verrez que la date a été prolongée.

Depuis un serveur membre du domaine, exécutez la commande :

gpupdate /force

Cela permettra de forcer la mise à jour des stratégies de groupe et de vérifier si le nouveau certificat d’autorité a bien été propagé.

En règle générale, si l’autorité de certification est intégrée à Active Directory, la distribution du certificat s’effectue automatiquement sur l’ensemble des machines du domaine.

Si ce n'est pas le cas, vous devriez la publier par GPO. Attention, cela est utile uniquement si ce n'est pas une autorité de certificat d'entreprise, car sinon, c'est automatique.

Voici comment il faudrait procéder. Pour ce faire, nous allons exporter notre certificat racine à partir du serveur d'autorité.

Retournez sur le certificat que vous venez de générer, ouvrez le menu "Propriétés", puis choisissez "Copier dans un fichier" afin d’exporter le certificat.

Cochez la première option pour obtenir un certificat CER puis cliquez sur "Suivant".

Choisissez le chemin d'export, puis cliquez sur "Suivant" et "OK" pour terminer.

Votre certificat sera bien exporté dans le chemin choisi, il ne vous reste plus qu'à le déployer par GPO.

D. Renouvellement du serveur intermédiaire

Sur le serveur d’autorité intermédiaire, la procédure de renouvellement est presque identique à celle de l’autorité racine.

Commencez par ouvrir la console Autorité de certification (certsrv.msc), puis effectuez un clic droit sur le nom de votre autorité et sélectionnez "Toutes les tâches", afin de choisir l'action "Renouveler le certificat d’autorité de certification".

Choisissez ensuite si vous souhaitez renouveler la clé de signature ou conserver l’existante.

Attention : pour garantir la cohérence de la hiérarchie de certification, le choix effectué ici doit être identique à celui appliqué lors du renouvellement du certificat racine.

Ainsi, si vous avez généré une nouvelle clé pour l’autorité racine, il est fortement recommandé d’en faire de même pour l’autorité intermédiaire

Choisissez ensuite le serveur d’autorité racine en ligne.

Dans notre cas, ce serveur est déjà démarré et intégré au domaine, il est donc directement joignable.

Il suffit alors de cliquer sur “OK” pour poursuivre le processus de renouvellement.

Attendez quelques secondes et votre nouveau certificat sera disponible.

Vous pouvez constater que le nouveau certificat intermédiaire a bien été émis par l’autorité racine, sa durée de validité est généralement inférieure à celle du certificat racine, ce qui est normal dans une architecture hiérarchique.

Par défaut la durée du modèle est de 2 ans. Si vous voulez prolonger cette durée à 5 ans par exemple, entrez les commandes suivantes dans une invite de commande sur le serveur d'autorité racine avant de renouveler votre certificat ou configurez tout simplement cela dans votre fichier CApolicy.inf.

Certutil -setreg CA\ValidityPeriodUnits 5
Certutil -setreg CA\ValidityPeriod "Years"
Restart-Service certsvc

Les certificats sont également accessibles depuis le répertoire par défaut du serveur, un emplacement pratique pour récupérer la liste de révocation CRL ou publier le CER. Accédez à ce répertoire :

C:\Windows\System32\CertSrv\CertEnroll

Maintenant que nos deux certificats, racine et intermédiaire, sont fonctionnels et accessibles, il est recommandé d’effectuer quelques tests de validation et de bonnes pratiques.

Commencez par demander un certificat depuis une machine membre du domaine afin de vérifier que la délivrance fonctionne correctement. Consultez ensuite les journaux d’événements pour vous assurer qu’aucune erreur n’est signalée, et pensez à réaliser un inventaire régulier afin de détecter toute anomalie ou échec d’émission.

Enfin, une bonne pratique consiste à publier une nouvelle liste de révocation (CRL) après un renouvellement.

Pour cela, effectuez un clic droit sur "Certificats révoqués", puis sélectionnez "Publier".

Choisissez une nouvelle liste et cliquez sur "OK".

E. Cas OCSP et renouvellement de CA

Si votre infrastructure utilise un serveur OCSP pour la vérification de révocation, lors du renouvellement de l’autorité de certification, exécutez :

certutil -setreg ca\UseDefinedCACertInRequest 1

Puis redémarrez le service CA. Cette commande permet à la CA de rester compatible avec l’OCSP Signing Certificate déjà en place.

Attention : si vous changez la paire de clés de la CA, vous devrez aussi recréer la liste de révocation pour l’OCSP. Ceci est précisé dans la documentation de Microsoft.

F. Renouvellement certificat hors ligne

La procédure de renouvellement d’une autorité de certification hors ligne ne diffère pas fondamentalement de celle d’une autorité en ligne. Il faut simplement démarrer le serveur concerné, activer le service de certification, puis relancer une demande de renouvellement.

Le nouveau certificat est alors généré.

La principale différence réside dans la publication des informations (CRL, AIA, etc.).

Certaines entreprises profitent de cette opération pour connecter le serveur au réseau afin d'effectuer les mises à jour, d'autres ne republient pas les nouveaux CRL racine vu que ce serveur n'est pas intégré dans le domaine ou reste injoignable, seuls les CRL des intermédiaires font foi.

Copiez le nouveau certificat sur le serveur intermédiaire afin de le publier manuellement dans l'AD.

À partir du serveur intermédiaire, entrez la commande suivante en prenant soin de bien remplacer le dossier ainsi que le nom du certificat :

certutil -dspublish -f C:\Temp\nom_du_certificat.cer RootCA

À ce stade, nous venons de renouveler le certificat d’autorité hors ligne et de le publier dans Active Directory. Vous pouvez vérifier dans la partition "Configuration" que ce dernier a bien été inscrit.

L’étape suivante consiste à signer la demande de renouvellement depuis le serveur intermédiaire.

G. Renouvellement du serveur intermédiaire offline

Comme vu précédemment, ouvrez la console Autorité de certification sur le serveur intermédiaire et lancez la procédure de renouvellement du certificat d’autorité.

Lors de la sélection du serveur racine, supprimez toute entrée existante si un serveur y apparaît déjà. Vous constaterez ensuite que le fichier de demande sera généré par défaut sur le disque C:\ du serveur.

À cette étape, cliquez simplement sur "Annuler", car la signature devra être réalisée manuellement à partir du serveur racine offline.

Sur la racine du disque C:\, récupérez le fichier de demande de certificat (.REQ) qui vient d’être généré.

Ce fichier devra ensuite être copié sur le serveur racine hors ligne, à l’aide d’un support amovible sécurisé (clé USB chiffrée, disque externe, etc.), afin d’y être signé manuellement

Nous avons copié la demande du renouvellement dans un dossier sur le serveur d'autorité racine, il nous reste plus qu'à effectuer la demande.

Faites un clic droit et dans la liste des tâches choisissez "Soumettre une nouvelle demande...".

Choisissez votre demande de certificat et cliquez sur "Ouvrir".

Allez dans le menu "Demandes en attente" puis cliquez sur "Délivrer pour valider la demande de signature".

Une fois terminée, vous pouvez visualiser le nouveau certificat dans la rubrique "Certificats délivrés" de la console.

Nous devrions maintenant exporter le certificat au format P7b puis le copier sur le serveur intermédiaire.

Sélectionnez le certificat récemment généré, dans l'onglet "Détails" cliquez sur "Copier dans un fichier".

Dans l’assistant d’exportation, cochez l’option faisant référence à Standard PKCS#7 (.p7b) ainsi que l’option "Inclure tous les certificats dans le chemin d’accès de certification, si possible".

Donnez un nom au fichier puis cliquez sur « Suivant ».

Cliquez ensuite sur « Terminer ».

Copiez le fichier généré sur le serveur intermédiaire.

Ouvrez le gestionnaire du certificat, effectuez un clic droit sur la CA, et choisissez l’option « Installer un certificat d'autorité de certification… ».

Sélectionnez le certificat que vous venez de copier puis cliquez sur « Ouvrir ».

Vérifiez que le nouveau certificat a bien été enregistré.

Vérifiez si le certificat est bien enregistré dans l'AD et dans le magasin local, exécutez un gpupdate si besoin, généralement il suffit d'attendre un peu le temps que la réplication se fasse correctement.

À l’aide de l’outil PKIView, vous pouvez vérifier l’état de santé de votre infrastructure PKI, notamment le statut des certificats ainsi que la validité des enregistrements AIA associés aux nouveaux certificats

H. Publication du CRL offline

Pour ce faire, copiez le fichier CRL du certificat racine offline sur votre serveur intermédiaire, puis entrez la commande suivante en spécifiant le bon chemin et nom du certificat.

certutil -dspublish -f "C:\Temp\Nom_du_fichier.crl" "RootCA"

N'oubliez pas de lancer la commande avec un compte ayant les droits d'inscrire des CRL dans l'AD, en l'occurrence Admin du domaine.

Si tout s’est déroulé correctement, vous devriez retrouver les informations liées à la liste de révocation (CRL) directement dans ADSI Edit, confirmant ainsi leur publication dans Active Directory.

IV. Vérification

À l’aide de l’outil PKIView, vous pouvez vérifier l’état de santé de votre infrastructure PKI, notamment le statut des certificats ainsi que la validité des enregistrements AIA associés aux nouveaux certificats.

Si tout s’est déroulé correctement, vous devriez retrouver les informations liées à la liste de révocation (CRL) directement dans ADSI Edit, confirmant ainsi leur publication dans Active Directory.

Continuez la vérification à l'aide des tâches post-installation décrites dans l'article suivant.

• Cours AD CS - Installation de l'autorité racine AD CS

Il est tout à fait possible d’effectuer l’ensemble de ces opérations en ligne de commande à l’aide de l’outil Certutil. Cependant, cette approche n’apporte pas de réel gain d’automatisation, car le renouvellement d’une autorité de certification reste une opération ponctuelle et sensible.

Dans ce guide, nous avons donc choisi de détailler la procédure pas à pas via l’interface graphique, afin de mieux comprendre chaque étape avant d’envisager une automatisation.

Encapsuler l’ensemble du processus dans un script PowerShell ou batch peut s’avérer risqué si la PKI n’est pas parfaitement maîtrisée. Pour plus de détails sur les commandes disponibles, vous pouvez consulter la documentation officielle Microsoft

• Documentation de certutil

V. Conclusion

Nous avons vu tout au long de cet article que le renouvellement d’un certificat d’autorité ne se limite pas à une simple opération technique : il s’agit d’une étape stratégique qui doit s’inscrire dans la politique de sécurité de l’organisation.

Dans les environnements complexes ou de grande envergure, cette opération exige une préparation minutieuse et des validations préalables afin d’éviter toute interruption de service. L’action en elle-même n’est pas difficile, mais les choix effectués (conserver ou non la clé, modifier l’algorithme, etc.) peuvent avoir un impact significatif sur l’ensemble de l’infrastructure.

Enfin, un rollback n’est pas toujours possible en dehors d’une restauration complète. Il est donc essentiel de planifier chaque étape, de vérifier vos sauvegardes et de valider les prérequis sur tous les serveurs concernés avant toute action.

Envie d'apprendre à installer et configurer une CA avec AD CS ? Retrouvez notre cours complet :

• Maîtrisez l’Autorité de certification avec AD CS sous Windows Server