Migrer SHA-1 à SHA-2 dans Windows AD CS

 

Dans cet article nous allons voir comment passer du SHA1 au SHA2 dans une autorité de certification d'entreprise Microsoft. L'exemple présenté ci-dessous a été réalisé sur un serveur AD CS en Windows 2012 R2. Le rôle de contrôleur de domaine est hébergé par un autre serveur Windows 2012 r2. Avant de migrer notre autorité de certification nous allons commencer par présenté les problèmes de compatibilité qui peuvent se présenter.

XP SP3 supporte SHA2 alors que W2003 SP2 ne le supporte pas en natif et ne peut valider la signature du certificat. Pour les 2 cas ils ne peuvent demander des certificats à une autorité sur 2008 et supérieur. Pour ajouter le support du SHA2 il faut ajouter la mise à jour suivante qui n'est pas incluse dans Windows Update.

Mise à jour pour Windows XP SP3 et Windows 2003 SP2 : https://support.microsoft.com/en-us/kb/968730

Avec cette mise à jour les clients XP SP3 et 2003 SP2 ne peuvent demander que des certificats V2, les V3 échoueront. Toutes les versions antérieures ne pourront prendre en charge la signature SHA2. A partir de Windows Vista et 2008 le SHA-2 est disponible par défaut.

En plus des problèmes de système d'exploitation la signature des mails avec S/MIME peut également poser des problèmes surtout sur des postes avant Windows 7 et une version Outlook antérieur à 2007.

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

Il reste encore des éléments à analyser avant de migrer vers SHA-2. En effet il faut encore valider la compatibilité d'application utilisant des certificats. Prenons par exemple System Center Configuration Manager 2012, le lien suivant https://technet.microsoft.com/fr-fr/library/gg699362.aspx indique que le SHA-2 est pris en charge mais pas partout. En effet dans la partie concernant « Point de service hors bande » seul les certificats SHA1 sont pris en charges.

Donc la première étape avant de migrer vers du SHA2 est de valider la compatibilité des différents éléments qui utilisent des certificats.

L'étape suivante est de déterminer quel fournisseur cryptographique est actuellement utilisé et s'il est compatible avec le SHA2. Dans l'image ci-dessous sur notre serveur Windows 2012 le provider par défaut est « Microsoft Software Key Storage Provider » (voir http://pbarth.fr/node/165 ) et supporte le SHA2 voir au-delà.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Pour plus d'information vous pouvez consulter le lien :

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931357(v=vs.85).aspx

Par exemple si vous utilisez « Microsoft Base Cryptographic Provider v1.0 » vous verrez qu'il n'utilise que le SHA1, alors que « Microsoft Base Smart Card Crypto Provider » utilisé pour l'authentification par carte à puce supporte le SHA2.

En affichant le certificat de l'autorité de certification nous pouvons constater que l'algorithme de la signature est bien du SHA1. En plus de modifier la configuration de l'autorité pour utiliser des signatures en SHA2 dans les nouveaux certificats, il faudra également renouveler le certificat de l'autorité.

Les paramètres de l'autorité de certificats sont enregistrés dans le registre de Windows. Vous pouvez utiliser la commande « certutil » pour lire cette valeur : « certutil –getreg CA\CSP\Provider ».

Si vous utiliser un autre provider qui ne supporte pas le SHA1, vous devrez le modifier. Le lien ci-contre explique par exemple la migration vers des fournisseurs récent (CNG : Cryptography API: Next Generation) : https://technet.microsoft.com/fr-fr/library/dn771627.aspx, l'opération est un peu plus complexe que dans notre exemple qui utilise déjà un provider récent.

Vous pouvez également utiliser la commande « certutil –getreg CA\CSP\CNGHashAlgoritm » pour vérifier l'algorithme utilisé.

Si vous ouvrez le registre (regedit), vous retrouverez les valeurs lu par « certutil » :

Pour modifier l'algorithme il suffit d'exécuter la commande « certutil –setreg ca\csp\CNGHashAlgorithm SHA256 » :

NOTE : n'oubliez pas de sauvegarder votre autorité !

La valeur dans le registre a été modifiée :

 

Nous allons maintenant arrêter et redémarrer les services de certificat.

Dans les propriétés de l'autorité de certification nous constatons que l'algorithme est bien « SHA256 ».

 

Néanmoins le certificat racine de l'autorité de certification n'est pas remplacé. Il s'agit toujours d'un certificat SHA1.

 

Nous allons maintenant renouveler le certificat de l'autorité :

Confirmer l'arrêt des services par oui :

Cliquez sur OK dans la fenêtre « renouveler le certificat d'autorité de certification ».

Un nouveau certificat apparait dans les propriétés de l'autorité : « Certificat n°1 »

Ce certificat utilise bien un algorithme de hachage « SHA256 » :

Sur les postes clients le nouveau certificat est automatiquement ajouté dans le magasin des « autorités de certification racines de confiance » si vous utilisez une autorité d'entreprise.

Je vous conseille également la lecture des articles suivants avant de mettre à niveau votre CA :

http://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx#Other_Major_Vendor_SHA-2_Support_Statements

https://gallery.technet.microsoft.com/migrating-sha-1-to-SHA-2-82ee3a4e

http://blogs.technet.com/b/askds/archive/2015/04/01/migrating-your-certification-authority-hashing-algorithm-from-sha1-to-sha2.aspx

 

 

 

 

 

Theme: 

Systeme: 

Annee: 

Commentaires

Erreur de frappe

Bonjour,

Petite erreur à la ligne "Vous pouvez également utiliser la commande « certutil –getreg CA\CSP\CNGHashAlgoritm » pour vérifier l'algorithme utilisé."
il manque le h avant le m à CNGHashAlgorithm

certificat 0 et certificat 1

Bonjour. Votre article est très interessant ! Une petite question, au moment où on renouvelle le CA. Dans la fenêtre il y a le certif N°0 et le certifi N°1. les clients qui ont leur ancien certificat (hors domaine), délivré avec le CA en SHA1, vont t-ils continuer fonctionner le temps de leur générer un nouveau certificat ? la CA est-il tjs en mesure de valider les anciens certifs qu'il avait généré ou il faut tout reprendre ? merci.

Re : certificat 0 et certificat 1

Oui l'ancien certificat reste valide tant que le certificat d'origine est dans la liste des autorité racine sur le poste client et que la date n'est pas révolue. Néanmoins certains navigateur peut émettre un avertissement sur le fait qu'il ne prend pas en charge la signature SHA1 (dans ce cas l'avertissement existe avant l'opération de remplacement). La CA continue de publier une liste de révocation correspondant à l'ancien certificat.

Autorité Racine

Bonjour,
Merci pour votre article, j'ai une question qui s'écarte un peu du sujet mais peut être pouvez-vous m'éclairer.
Nous avons besoin de garder une AC en SHA1 pour signer les certificats des applications non compatibles SHA2. Nous avons également une AC SHA2.
Ma question est la suivante, si notre autorité racine est en SHA2 les applications incompatibles signées par l'AC en SHA1 pourront-elles lire la chaine de certification (sachant que la racine est en SHA2) ? Ou alors il nous faut une autorité racine en SHA1 et une SHA2 ?

info

Bonjour ,
je suis un fan de votre site ,vous faite un excellent travail ,
j'aimerai partager des articles sur le MDT que je m'aitrise et surtout des astuces que j'ai trouvé et publier sur le site de microsoft ,ca me fera un immense plaisir ,de voir autre personnes s'en servir ,
voila ,cordialement ,

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
CAPTCHA
Cette question empêche les soumissions de spam automatisées. Merci de votre compréhension
1 + 0 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.