Active Directory Certificates Services – quelle architecture dois-je déployer ?

Lors du déploiement d’une nouvelle autorité de certification, 3 questions reviennent systématiquement :

• Dois-je déployer une autorité de certification 1 tiers, 2 tiers ou 3 tiers ?
• Quel algorithme de chiffrement et quelle taille de clé privée / publique dois-je utiliser ?
• Quel algorithme de Hash dois-je utiliser ?

Architecture d’autorité de certification : 1 tiers, 2 tiers ou 3 tiers

Si un attaquant arrive à obtenir la clé privée du certificat de votre autorité de certification, il peut alors restaurer/réinstaller cette dernière et générer tous les certificats qu’ils souhaitent en usurpant l’identité de votre entreprise.

Votre autorité de certification est alors compromise et doit être complètement réinstallée avec l’utilisation d’une nouvelle paire de clés privées / publiques. Tous les certificats que vous avez émis avec votre ancienne autorité de certification doivent être révoqués et remplacés par des certificats de la nouvelle autorité de certification.

Les entreprises qui émettent des milliers voir des millions de certificats utilisent en général plusieurs autorités de certification. Ce mode de fonctionnement permet de limiter l’impact en cas de compromission d’une des autorités de certification.

De plus dans le cas d’une autorité de certification Microsoft, certains paramètres comme la configuration de CRL (durée de vie, emplacement), l’archivage des clés privées, l’audit ou la mise en œuvre de la séparation des rôles ne peuvent être configurés qu’au niveau de l’autorité de certification et non au niveau du modèle de certificats.

Les autorités de certification comme Microsoft Active Directory Certificates Services permettent de créer des arborescences d’autorités de certification.

On parle d’autorité de certification 1 Tier, soit à un niveau, quand l’autorité de certification racine est aussi l’autorité de certification qui émet les certificats pour les utilisateurs finaux. Dans le cas d’une autorité de certification Microsoft, elle doit être de type Entreprise pour permettre de bénéficier de toutes les fonctionnalités comme les modèles de certificats ou l’archivage des clés privées. Cette architecture est la plus simple à mettre en œuvre et à maintenir (un seul serveur).

Ce type d’architecture convient parfaitement si vous devez émettre moins de 10000 certificats et si votre autorité de certification n’est pas reconnue comme autorité racine de confiance par les autres entreprises.

On parle d’autorité de certification 2 tiers, soit à 2 niveaux quand on dispose :

• D’une autorité de certification racine qui sert uniquement à générer le certificat des autres autorités de certification. Comme la clé privée de cette autorité de certification est très critique, son niveau de sécurité doit être maximum. Microsoft recommande que l’autorité de certification racine soit déployée dans un groupe de travail (machine non membre du domaine), dans un réseau et un centre de données sécurisé et qu’elle soit arrêtée. Microsoft recommande uniquement une maintenance périodique pour renouveler la CRL de l’autorité de certification racine.
• Une ou plusieurs autorités de certifications émettrices. Cette architecture permet de disposer d’une configuration spécifique pour chaque autorité de certification et de dédier chaque autorité de certification pour une fonction spécifique ou à un client spécifique.

Ce type d’autorité de certification convient parfaitement aux entreprises qui souhaitent émettre plusieurs milliers de certificats ou/et qui sont soumises à des règles de sécurité renforcée (secteurs comme les banques, assurances).

On parle d’autorité de certification 3 tiers, soit 3 niveaux, quand on ajoute un niveau supplémentaire de protection entre l’autorité de certification racine et l’autorité de certification émettrice de certificats pour les utilisateurs finaux. Cette autorité de certification est appelée autorité de certification subordonnée.

Ce type d’architecture est recommandée si votre autorité de certification est reconnue comme une autorité racine de confiance par défaut sur tous les systèmes d’exploitation (cas d’une autorité de certification publique) ou que vous émettez plusieurs milliers / millions de certificats.

Avec une architecture 2 ou 3 tiers, si une autorité émettrice est compromise, l’administrateur peut révoquer le certificat de l’autorité de certification émettrice depuis l’autorité de certification subordonnée (3 tiers) ou racine (2 tiers). Cette simple action suffira pour invalider tous les certificats générés par l’autorité de certification compromise. En effet, pour qu’un certificat soit valide, il faut que :

• Le certificat ne soit pas révoqué ou expiré.
• Le certificat de toutes les autorités de certification du chemin d’approbation ne soit pas révoqué ou expiré.

Pour rappel, le chemin d’approbation d’un certificat contient la signature de l’autorité de certification qui a émis le certificat et le certificat de l’autorité de certification qui a elle même signé le certificat de l’autorité de certification émettrice (et ainsi de suite).

On notera qu’il n’est pas possible de révoquer le certificat d’une autorité de certification racine.

Sous Windows, le système est préconfiguré avec une liste d’autorité de certification racine de confiance. Il est possible d’ajouter ou supprimer des autorités de certification dans cette liste. Pour visualiser sous Windows 10, le magasin Autorité de certification racine de confiance, taper la commande CERTLM.MSC puis aller dans le nœud Trusted Root Certification Authorities | Certificates.

Choix de l’algorithme de chiffrement et de la taille de clés

Une autorité de certification sous Windows 2012 R2 supporte plusieurs types d’algorithme de chiffrement :

• Microsoft Enhanced Cryptographic Provider v1.0 : ancien algorithme de chiffrement non sécurisé.
• Microsoft Base Cryptographic Provider v1.0 : ancien algorithme de chiffrement non sécurisé.
• Microsoft Strong Cryptographic provider : ancien algorithme de chiffrement non sécurisé
• RSA#Microsoft Software Key Storage Provider : algorithme de chiffrement asymétrique basé sur RSA. Cet algorithme est sécurisé avec une taille de clé importante (2048 ou 4096).- ECDSA_P256, ECDSA_P384 et ECDSA_P521 : il s’agit d’un algorithme de chiffrement asymétrique qui permet un niveau de sécurité équivalent à RSA mais avec une clé plus petite. Une clé ECDSA 256 bits permet un niveau de sécurité identique/ supérieure à une clé RSA 2048 bits comme expliqué dans l’article https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/.

Cependant cet algorithme n’est pas pris en charge par tous les périphériques.

• Microsoft ne supporte plus l’utilisation de clé de chiffrement RSA dont la taille est inférieure à 1024 bits comme expliqué dans l’article :
  https://support.microsoft.com/en-us/kb/2661254
  
• Des chercheurs de l’Université de Michigan ont récemment remis en cause la sécurité de l’algorithme de chiffrement asymétrique RSA avec une taille de clés de 1024 bits :
  http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits
  
• Les clés RSA de 2048 bits seront supportées jusqu’en 2030 comme indiqué dans les articles suivants :
  https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand
  
• Certains équipements ont des problèmes pour prendre en charge des tailles de clés supérieurs à 2048 bits comme certains téléphones VOIP Polycom ou certains équipements réseaux Cisco. Pour plus d’informations :
  https://www.yubico.com/2015/02/key-size-matter-cryptography/

Je vous préconise donc d’utiliser l’algorithme de chiffrement RSA#Microsoft Software Key Storage Provider avec une taille de clé de 2048 bits au niveau des autorités de certification racine et émettrice.

Choix de l’algorithme de Hash

 L’algorithme de Hash SHA 1 est déprécié et ne doit plus être utilisé.

SHA 256 est correctement pris en charge par tous les navigateurs récents :
https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Les algorithmes de Hash SHA 2 (SHA 256, SHA 384 et SHA 512) nécessitent l’installation d’un correctif sur les machines Windows XP Pro et Windows 2003 Server. Pour un fonctionnement optimal sur ces 2 systèmes, il est recommandé de déployer le correctif http://support2.microsoft.com/kb/2868626 qui apporte la bonne version de la DLL Crypt32.dll (5.131.3790.5235). Ce correctif peut être téléchargé à cette adresse :

• https://technet.microsoft.com/en-us/library/security/ms13-095.aspx

Il remplace les correctifs KB 968730 et KB 938397 sur les machines Windows XP / 2003 :

• https://support.microsoft.com/fr-fr/kb/968730
• https://support.microsoft.com/en-us/kb/938397

Le correctif 2763674 (https://support.microsoft.com/en-us/kb/2763674) doit être déployé sur les machines Windows 2008 R1 et Vista pour la prise en charge des algorithmes SHA 2. On notera que :

• Il n’est pas possible de faire du S/MIME sur une machine Windows XP avec des certificats utilisant un des algorithmes de Hash SHA2 même après l’installation du correctif ci-dessous.
• SHA-224 n’est pas supporté par Microsoft et ne doit pas être utilisé.
• SHA 512 n’est pas activé par défaut et nécessite l’installation d’un correctif spécifique sur Windows 7 / Windows 2008 R2 :
  • https://support.microsoft.com/en-us/kb/2973337

Pour cette raison, je vous préconise de sélectionner SHA 256 comme algorithme de Hash pour le certificat de l’autorité de certification.

Pour aller plus loin

Nous vous invitons à lire ces articles :

• http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx
• http://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx
• http://ammarhasayen.com/2015/02/02/pki-certificate-services-sha-1-deprecation/
• http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx