Etude de cas — Automatisation & PKI
Renouveler un wildcard sur un parc hybride : auditer, tester, migrer sans coupure — et pouvoir revenir en arriere
Comment j'ai industrialise avec Ansible le renouvellement du certificat TLS wildcard d'un organisme de formation professionnelle multi-sites — de l'audit automatise du parc Windows/Linux jusqu'a la migration sans coupure, rollback compris.
- 3
- serveurs migres sans aucune coupure de service
- 2
- deploiements de certificat expire evites par le controle OpenSSL
- < 2 min
- de retour arriere documente par serveur
- ~200 j
- le cycle de renouvellement, desormais repetable tel quel
Le contexte
Un organisme de formation professionnelle multi-sites doit renouveler le certificat TLS wildcard de son domaine, utilise a des endroits que personne ne connait precisement : une vingtaine de serveurs Windows et Linux dans Azure, plus des equipements reseau et services SaaS. Symptome revelateur du manque de visibilite : le serveur d'impression presentait un certificat expire depuis un an sans que personne ne l'ait remonte.
Contrainte supplementaire : suite a l'evolution des regles des AC publiques (2026), les certificats emis ont desormais une duree de vie d'environ 200 jours — l'operation manuelle d'hier doit devenir un processus repetable deux fois par an.
La demarche
- 01
Audit automatise du parc
J'ai ecrit un playbook Ansible d'inventaire execute sur l'ensemble des serveurs (Windows via WinRM, Linux via SSH). Cote Windows : parcours des magasins de certificats et interrogation des ports en ecoute (HTTPS, RDP, LDAPS...). Cote Linux : recherche des fichiers de certificats dans les emplacements standards et test des ports TLS locaux, avec filtrage sur le CN/SAN du wildcard. Resultat : trois serveurs reellement concernes — et surtout l'elimination methodique des faux positifs (certificats RDP auto-signes par machine, certificats de la PKI interne), qui auraient fait perdre du temps en migrations inutiles.
- 02
Second audit oriente migration
Un playbook plus profond pour repondre a « qu'est-ce qui utilise ce certificat et comment » : appariement certificat/cle privee par comparaison de modulus, recherche des fichiers de configuration referencant chaque certificat (vhosts Apache), bindings IIS et http.sys, processus ecoutant sur chaque port. Decouvertes : la meme cle privee reutilisee a chaque renouvellement depuis trois ans, des copies et millesimes expires accumules dans les repertoires, et le perimetre exact des services a recharger.
- 03
Plan de migration outille
Plan phase (preparation, test, serveurs internes, services externes, nettoyage) injecte dans l'outil de gestion de projet de l'equipe via son API GraphQL : un script Python cree les groupes par phase, les taches et leurs modes operatoires en commentaire, et la procedure de rollback documentee par serveur directement dans la tache correspondante. Principe de securite du script : le token d'API n'est jamais stocke dans le code (saisie masquee ou variable d'environnement).
- 04
Banc de test representatif
J'ai ajoute un clone de test du serveur ITSM a l'inventaire Ansible, puis aligne son vhost sur l'etat exact de la production — il servait un certificat auto-signe par defaut. Un test n'a de valeur que s'il reproduit ce qu'on va reellement faire en prod.
- 05
Controle du certificat recu
Verification systematique du PFX a l'OpenSSL avant tout deploiement : notAfter, correspondance modulus certificat/cle, presence de chaine. C'est l'etape qui a tout sauve — voir l'encadre ci-dessous.
- 06
Playbook de migration avec garde-fous
Un playbook unique par serveur Linux : pre-verifications sur le controleur (existence du certificat, correspondance cert/cle, arret immediat sinon), sauvegarde horodatee du vhost, releve du certificat presente avant, deploiement cert+cle avec les bonnes permissions, bascule des directives SSL du vhost, configtest obligatoire avant reload (arret sans toucher au service si la syntaxe est cassee), reload sans coupure, puis assertion finale : le port doit presenter le nouveau certificat, different de l'ancien. Valide sur le banc de test, puis rejoue a l'identique sur les deux serveurs Apache de production.
- 07
Cas Windows / IIS
Import du PFX dans le magasin machine (mot de passe jamais passe en clair dans une commande — saisie masquee cote controleur), rebind du port 443 sur la nouvelle empreinte, gestion du piege wildcard vs nom court (un wildcard ne couvre que les FQDN — les acces par nom NetBIOS declenchent un avertissement legitime), et finition UX : redirection de la racine IIS vers le portail d'impression du constructeur plutot que la page IIS par defaut.
- 08
Rollback jamais utilise, mais toujours possible
La migration ne supprime rien : anciens certificats et sauvegardes de vhosts conserves jusqu'a une phase de nettoyage separee, executee seulement apres validation complete. Retour arriere documente a moins de deux minutes par serveur.
L'architecture
Les resultats
- Trois serveurs migres sans aucune coupure de service (reload Apache, sessions applicatives conservees) et sans rollback necessaire
- Un certificat expire depuis un an en production, detecte par l'audit et corrige
- Un deploiement de certificat expire evite deux fois grace au controle OpenSSL systematique des fichiers recus
- Un processus repetable : playbooks d'audit et de migration reutilisables tels quels au prochain cycle (~200 jours), la prochaine iteration se resumant a deposer le nouveau PFX et rejouer
- Un plan projet complet, avec procedures et rollback embarques dans chaque tache
Competences mises en oeuvre
- Ansible (playbooks, vault, inventaire multi-OS)
- WinRM / SSH
- OpenSSL & PKI (X.509, PKCS#12, modulus, chaines)
- Apache (vhosts, configtest, reload sans coupure)
- IIS (magasins de certificats, SSL bindings, http.sys)
- PowerShell
- Bash
- Azure
- API GraphQL (automatisation d'outil projet)
- Gestion des secrets (vault, saisie masquee, tokens)
- Methodologie (audit → test representatif → prod, rollback systematique, nettoyage differe)
Une operation critique a industrialiser ?
Audit, automatisation, garde-fous et rollback : parlons de votre contexte.