Renouvelez votre autorité de certification racine Active Directory Certificate Services (AD CS) pour signer en SHA‑256 plutôt qu’en SHA‑1, sans reconstruire l’ensemble de votre infrastructure PKI : découvrez la méthode, les bonnes pratiques, les pièges et les commandes indispensables.
Vue d’ensemble de la transition SHA‑1 → SHA‑256
Depuis 2017, les principaux éditeurs (Microsoft, Apple, Google, Mozilla) refusent les certificats publics signés en SHA‑1. Si la contrainte n’est pas encore absolue dans un réseau privé, persister avec SHA‑1 expose à un risque de collision et à un déclassement de la sécurité des échanges TLS internes. La bonne nouvelle : une Enterprise Root CA Windows Server peut être mise à jour en seulement quelques heures, sans réinstaller la PKI ni toucher à la chaîne de confiance existante.
Pourquoi abandonner SHA‑1 ?
- Intégrité fragile : des attaques pratiques ont montré que deux fichiers différents peuvent partager la même empreinte SHA‑1.
- Conformité : de nombreux référentiels de sécurité (PCI‑DSS, ANSSI, NIST, ISO 27001) proscrivent SHA‑1 pour la signature de certificats.
- Périmètre cloud et hybride : les passerelles M365, Azure AD Application Proxy et les appliances WAF modernes déclenchent des alertes lorsqu’une chaîne contient SHA‑1.
- Écosystème futur : HTTP/3, TLS 1.3, QUIC, Zero Trust Network Access exigent des suites cryptographiques récentes.
Conditions préalables et vérifications
- Niveau fonctionnel de domaine : Windows Server 2008 ou supérieur suffit, mais Server 2016+ simplifie la gestion CNG.
- Compatibilité poste client : Windows XP SP3 et Server 2003 nécessitent des correctifs spécifiques pour SHA‑256 ; certains drivers d’imprimante, scanners réseau et terminaux IoT peuvent aussi être concernés.
- Accès administrateur : un compte Enterprise Admins ou équivalent est requis pour modifier la configuration de la CA et déployer la nouvelle racine via stratégie de groupe.
- Ressources : prévoir un créneau de maintenance (30 min – 1 h) pour le renouvellement et le redémarrage du service
CertSvc.
Procédure détaillée
| Étape | Actions essentielles | Points de vigilance |
|---|---|---|
| 1. Analyse d’impact | Recenser toutes les applications, systèmes, périphériques et appliances réseau validant des certificats émis par la CA. | • Windows XP/2003, versions Android < 5, firmwares anciens peuvent refuser SHA‑256. • Créer un laboratoire de test représentatif. |
| 2. Vérification de la santé PKI | Lancer pkiview.msc ; vérifier AIA/CRL/Delta CRL. | Corriger tout avertissement (chemin inaccessible, CRL expirée) avant de continuer. |
| 3. Sauvegarde complète | • Exporter la clé privée et la base de données de la CA. • Capturer l’état système ou un instantané VM. | Permet un retour arrière en cas d’échec. |
| 4. Basculer SHA‑256 par défaut | certutil -setreg ca\csp\CNGHashAlgorithm SHA256 net stop certsvc && net start certsvc | Ne s’applique qu’aux certificats émis après redémarrage. |
| 5. Renouveler le certificat de la CA | Console Certification Authority → clic droit sur la CA → All Tasks ▸ Renew CA Certificate ▸ Same key. | • Conserver la même clé maintient la chaîne existante. • Choisir « New key » uniquement si l’algorithme ou la taille de clé doit aussi évoluer. |
| 6. Publier la nouvelle racine | Copier le .crt dans %windir%\System32\certsrv\certenroll. Pousser via GPO : Computer Configuration ▸ Policies ▸ Windows Settings ▸ Security ▸ Public Key Policies ▸ Trusted Root Certification Authorities. | Pour les hôtes hors domaine, distribuer manuellement (e‑mail, MDM, script PowerShell). |
| 7. Ré‑émission progressive des certificats | Les certificats existants restent valides. À l’expiration ou à la ré‑émission forcée, ils seront signés en SHA‑256. | Si un service exige SHA‑256 immédiatement, ré‑émettre manuellement ses certificats. |
| 8. Supervision et plan de secours | Surveiller les journaux Application et System (ID 100–101 CertSvc) ; exécuter périodiquement pkiview.msc. | Conserver la sauvegarde initiale jusqu’à la fin de la phase de transition. |
Bonnes pratiques complémentaires
- CNG/KSP : si votre CA utilise encore CSP (CryptoAPI hérité), envisagez la migration vers un provider CNG pour préparer l’adoption de SHA‑384/512 ou de la cryptographie elliptique.
- Double signature racine (optionnel) : conserver l’ancienne racine SHA‑1 dans le magasin Trusted Root le temps que les derniers équipements soient renouvelés, puis la supprimer.
- Renouvellement automatique des certificats client : configurez un auto‑enrollment GPO afin que les machines et comptes utilisateur renouvellent leurs certificats dès qu’ils atteignent 80 % de leur durée de vie.
- Audit et inventaire : exécutez
Get-ChildItem -Path Cert:\ -Recursesur un échantillon de postes pour repérer les certificats encore signés SHA‑1. - Contrôle de conformité SSL/TLS : lancez un scanner interne (par ex. OpenSSL s_client, testssl.sh ou un SAST) pour identifier les services publiant une chaîne SHA‑1.
Gestion des dispositifs hérités
Il n’est pas toujours possible de remplacer immédiatement tous les équipements. Les options :
- Firmware/patch : certains constructeurs fournissent un microprogramme ajoutant la prise en charge de SHA‑256 (copieurs, pare‑feux, load balancers).
- Sous‑chaîne intermédiaire : émettre un certificat intermédiaire SHA‑1 signé par la racine SHA‑256 puis signer l’appareil avec cette intermédiaire.
Attention : n’utilisez cette méthode qu’en dernier recours ; elle complexifie la chaîne de confiance. - Isoler le flux TLS : placer l’appareil derrière un reverse‑proxy qui termorera TLS avec un certificat valide SHA‑256, puis relaiera en clair ou en TLS interne.
- Plan de retrait : documenter une date limite d’abandon, après laquelle la compatibilité SHA‑1 ne sera plus garantie.
Plan de communication
- Phase 1 – Annonce : informer les équipes IT & Dev des dates de bascule, rappeler la liste d’adresses IP/ports à surveiller.
- Phase 2 – Maintenance : pendant le redémarrage du service
CertSvc, les demandes de certificats sont en file d’attente ; aucun impact pour l’authentification ou les sessions TLS établies. - Phase 3 – Validation : partager un check‑list de tests (connexion RDP, portail VPN, messagerie, IIS, SQL Server, LDAPS).
- Phase 4 – Clôture : publier un rapport listant les certificats ré‑émis et le nombre d’appareils restants en SHA‑1.
Foire aux questions
Dois‑je générer une nouvelle paire de clés pour la CA ?
Pas nécessaire si la clé actuelle est au moins RSA 2048 bits et si votre politique ne l’exige pas. La conservation de la clé évite de redéployer la racine sur chaque machine et limite la ré‑émission des certificats intermédiaires.
Et si ma CA tourne sous Windows Server 2003 ?
Server 2003 ne supporte pas SHA‑256 pour la racine. Il faudra migrer la CA vers une version prise en charge (processus backup / install / restore sur un OS plus récent), puis appliquer la présente procédure.
Le basculement vers SHA‑256 impacte‑t‑il les smartcards ?
Les cartes à puce récentes (Gemalto, Yubikey, Feitian) gèrent SHA‑256 nativement. Vérifiez cependant le minidriver ; certaines cartes GIDS anciennes ne fonctionnent qu’en SHA‑1.
Comment contrôler qu’un certificat est signé en SHA‑256 ?
Ouvrez le certificat, onglet Détails : le champ « Signature algorithm » doit indiquer sha256RSA. En CLI : certutil -dump moncert.cer | findstr /i "Signature Algorithm".
Conclusion
En suivant cette feuille de route, vous modernisez votre Root CA sans interrompre la production, tout en préparant votre SI aux exigences cryptographiques des prochaines années. Anticipez la fin de vie des équipements obsolètes, automatisez la ré‑émission des certificats et gardez la main sur votre confiance numérique.