Jusque-là, nous avons installé une nouvelle autorité de certification qui utilise le même nom et le même certificat que l'ancienne autorité (voir 1ère partie), mais avec un serveur et un OS plus récent (Windows Server 2022 dans notre exemple). Il nous faut encore restaurer la base de données de l'autorité provenant d'une sauvegarde récente de l'ancien serveur. Pour restaurer la base de données, il faut d'abord arrêter le service. Vous pouvez arrêter le service en ligne de commande (net stop certsvc ) , avec PowerShell ou depuis la console de l'autorité de certification. Depuis la console, faites un clic droit sur le nom de l'autorité, puis « toutes les tâches » et « arrêter le service ».
Pour restaurer la base de données de l'autorité, faites un clic droit sur le nom de l'autorité, puis « toutes les tâches » et « restaurer l'autorité de certification ».
Sur la page « bienvenue » de l'assistant de restauration, cliquez sur « suivant ».
Sur la page « élément à restaurer », cochez la case « base de données de certificats et journal de la base de données de certificats ».
Puis sélectionnez « parcourir » et indiquez l'emplacement de la sauvegarde de la base de données.
Sur la page « dernière étape », vérifiez les paramètres et cliquez sur terminer.
Sur le message d'avertissement, qui apparaît après la restauration de la base de données, nous allons cliquez sur « non » afin, de ne pas redémarrer tout de suite le service et restaurer d'abord les paramètres de l'autorité.
Faites un double clic pour importer dans le registre Windows les paramètres de l'autorité provenant de l'export sur l'ancien serveur ayant eu ce rôle. Lors la demande de confirmations, cliquez sur « oui ».
Sur le message d'information suivant, cliquez sur « OK ».
Nous pouvons maintenant redémarrer le service de l'autorité. Depuis la console « autorité de certification », cliquez sur « toutes les tâches » puis « démarrer le service ».
Comme nous avons repris les paramètres de l'autorité, à travers l'export du registre, nous pouvons retrouver les chemins identiques pour les URL de publications des CRLs. Il est important de conserver les mêmes chemins de publication, afin de respecter les informations présentes dans les certificats déjà émis.
Il est important de tester le fonctionnement de l'autorité comme la publication d'une nouvelle liste de révocation. Vous retrouverez dans le lien suivant les informations nécessaires pour publier une mise à jour de la liste de révocation.
Dans notre exemple, lors de la publication de la liste de révocations, nous pouvons voir apparaître une erreur, du fait que la liste est publiée sur un partage d'un autre serveur et que le compte de l'ordinateur de l'autorité de certification doit disposer de permissions sur ce dossier.
En ajoutant les autorisations pour le compte du serveur, l'erreur disparaît.
De la même manière si votre autorité publie des informations dans Active Directory, il faudra modifier les informations de sécurité pour le compte de l'ordinateur de l'autorité. Vous constaterez également la présence d'un SID non identifié, qui correspond au compte de l'ancienne autorité de certification qui a été supprimé.
Au niveau Active Directory, les informations sont par défaut enregistrées dans la partition de configuration. Vous pouvez utiliser un outil ADSIEdit, pour modifier les informations de sécurité sur les objets liés à la PKI. Pour cela ouvrez le conteneur « CN=Configuration », puis « CN=Services », « CN=Public Key Services », « CN=AIA » ou « CN=CPD » et enfin le nom de l'autorité. Vous pourrez ensuite ajouter les permissions pour le compte de l'ordinateur de l'autorité de certification.
Une fois l'opération terminée, il est recommandé de tester :
- La création d'un nouveau certificat
- La révocation d'un certificat
- La publication des certificats
- L'accès aux listes de révocations
Vous pouvez vous aider de « PKIView.msc ».
Si votre autorité a également des rôles de services comme le rôle d'inscriptions Web, le plus simple est de réinstaller et de reconfigurer le rôle. Il est possible après la reconfiguration de restaurer les paramètres IIS depuis une sauvegarde, mais ce n'est pas forcément utile.
Si votre autorité de certification héberge également les informations de l'autorité (AIA) et les listes de révocations, il est possible que certaines applications ne puissent valider le certificat pendant la phase de migration, l'ancien serveur étant arrêté.
Si comme dans notre exemple la publication de ses informations est réalisée sur un serveur Web tiers et que les URLs d'accès sont des alias et non le nom réel du serveur, il reste assez simple de migrer le serveur sans impacter le contrôle des certificats.
Les informations et les listes de révocations publiées dans l'annuaire Active Directory restent disponibles pendant la migration, si vos contrôleurs de domaine sont disponibles (c'est préférable ! ).
Si vous utilisez un répondeur OCSP et que le répondeur est sur le même serveur, il y a aura une interruption de ce service.
