Configuration d’une autorité de certification.
Configuration d’une autorité de certification
Cet article est une présentation de la configuration d’une autorité de certification (CA) dans l’objectif de délivrer des certificats pour une plateforme RDS. La configuration d’une telle plateforme fait l’objet d’un autre billet, posté par un de mes collègues.
La préparation de son article a mis en évidence le besoin de détailler au préalable la configuration de la CA pour être en mesure de délivrer les certificats nécessaires.
Autorité de certification
En cryptographie, l'Autorité de certification (AC ou CA) a pour mission, après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement, de signer, émettre et maintenir
- Les certificats (CSR : Certificate Signing Request)
- Les listes de révocation (CRL : Certificate Revocation List)
Sur le plan technique, cette infrastructure de gestion des clés permet ainsi d'assurer que
- Les données transmises n'ont pas été modifiées durant le transfert : intégrité par hachage des données
- Les données proviennent bien de l'émetteur connu : utilisation de clés et répudiation
La clé de chiffrement-déchiffrement est identique lors d'algorithmes symétriques dits à clef secrète (connue de l'émetteur et du destinataire) et différentes lors d'algorithmes asymétriques dits à clé publique (publique pour tout le monde, privée personnelle gardée secrètes). Les clés en jeu sont celles de l'émetteur et du destinataire.
Microsoft propose un rôle de serveur de certificat sur les versions serveur de Windows.
Certificate Revocation List Distribution Point (CDP)
Les listes de révocation contiennent les références des certificats que l'administrateur a révoqués. Elles ne contiennent pas les certificats expirés. Cette information est indispensable pour vérifier la validité d'un certificat. Chaque CA publie une CRL, qu'elle signe (avec sa clé privée donc).
Deux types de CRL existent. Les CRLs complètes, qui reprennent tous les certificats révoqués, et les delta CRLs qui ne contiennent que les certificats révoqués depuis la dernière publication de CRL complète. La fréquence de publication des secondes est supérieure à celle des premières.
Dans certains cas, l'utilisation de certificat privé par des clients sur Internet, il peut être nécessaire de rajouter un CDP public (ie accessible depuis Internet).
Pour cela, allons dans la console "Certification Authority" et ouvrons les propriétés de la CA.
Exemple d'extension CRL Distribution Point à ajouter :
https://MyPublicWebServer.myCompany.com/CerEnroll/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Ce CDP doit être inscrit dans les certificats émis et dans les CRL émises.
Il faudra ensuite mettre en place un mécanisme qui recopie la CRL depuis la CA (c:\windows\system32\certSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl) vers ce serveur web.
Authority Information Access (AIA)
Basiquement, il s'agit de l'emplacement où trouver le certificat de l'autorité de certification. Elle permet de télécharger le certificat pour construire la chaîne de publication, en cas d'architecture à plusieurs niveaux, et de comparer le certificat de la CA racine avec ceux présents dans le magasin de confiance.
En cas de client sur Internet, il faut également publier les informations de la CA de manière publique. C'est la seconde extension qu'il faut modifier de la même façon
AIA à ajouter :
Comme pour le CDP, ce fichier (c:\windows\system32\certSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt) devra être copié depuis la CA vers le serveur web publique.
Modèles de certificat
Microsoft propose des modèles de certificat pour les rôles les plus courants de certificats. Ceux-ci peuvent d'ailleurs être personnalisé pour les adapter à chaque besoin (durée de vie, contenu, protection des clés, …).
Les modèles de certificat existent dans toute Active Directory, mais seules les autorités de certification installée sur une version entreprise de Windows peuvent les prendre en charge.
En fait de personnalisation de modèle de certificat, c'est la duplication d'un modèle existant que l'on réaliser et on personnalise le nouveau modèle.
Exemple avec la personnalisation du modèle Web Server pour créer un modèle adapté à une architecture RDS par exemple. Etant donné que le même certificat doit être installé à plusieurs endroits, il faut pouvoir en exporter la clé privée. Voici comment procéder.
Première étape, ouvrons la console "Certificate Templates" et dupliquons le modèle Web Server.
Il nous fait au moins un modèle Windows Server 2003 Enterprise.
Appelons ce modèle "RDS Server"
Et marquons la clé privée comme exportable.
(La sécurité à mettre en œuvre au niveau de l’autorité de certififcation et au niveau du modèle est détaillée dans le paragraphe “Permissions”, plus loin dans cet article.)
Il faut maintenant rendre ce modèle disponible. Pour cela, allons dans la console "Certification Authority" et publions un nouveau modèle.
Clés exportables
Nous venons de modifier le modèle de certificat pour autoriser l'export des clés privées. Par défaut cela est désactivé, pour éviter de la mettre en danger. Une clé privée est générée sur la machine qui fait la demande et est associé au certificat une fois celui-ci émis. La clé privée est associée à la machine et n'a pas de raison d'être ailleurs.
Dans certains cas, il est nécessaire d'exporter cette clé. Soit pour des raisons de sécurité (sauvegarde du certificat et de sa clé, en parallèle de la sauvegarde de la machine) ou de fonctionnalité (utilisation d'un même nom pour plusieurs machines). C'est ce second scénario qui est suivi quand on construit une ferme de serveur IIS par exemple (utilisation d'un même nom DNS pour plusieurs adresses IP par exemple). Dans ce cas, le même certificat doit être présent sur plusieurs machines.
Il faut alors demander un certificat avec le nom "virtuel", partagé par toutes les machines depuis un des nœuds, exporter le certificat et la clé privée, puis l'importer sur les autres nœuds de la ferme.
Voici, par exemple, comment exporter le certificat depuis le magasin de certificat utilisateur et l'importer dans le magasin de certificats machine. C'est la même logique pour une copie entre machine.
Tout d'abord, ouvrir une console MMC et charger deux fois le composant certificat, une fois pour la machine, une fois pour l'utilisateur. Ensuite, depuis le magasin personnel de l'utilisateur, exporter le certificat avec sa clé privée.
L'option d'exporter la clé privée ne sera disponible que si elle est exportable. Cela se définit dans le modèle, comme vu plus haut, ou au moment de l'import, comme nous verrons plus bas.
Il faut ensuite l'importer dans le magasin de l'ordinateur.
A cette étape également on peut marquer la clé privée comme exportable
Attention ! Bien qu'il soit possible de faire un glisser-déplacer du certificat d'un magasin vers un autre, cela ne déplace pas la clé privée. Il en résulte un certificat dans le magasin machine, mais une clé privée dans le magasin utilisateur. Comme l'utilisateur affichant la console aura accès aux deux, il verra que la clé privée est bien accessible, mais en pratique, elle ne le sera pas par la machine.
Voici les informations d'un certificat déplacé. Dans un premier temps récupéré dans le contexte de l'utilisateur.
C:\>certutil –verifystore my
================ Certificate 3 ================
Serial Number: 14890a70000000000005
Issuer: CN=vpcw2k3ca, DC=vpcw2k3, DC=local
Subject: CN=Administrator, CN=Users, DC=vpcw2k3, DC=local
Certificate Template Name: EFSRecovery
Non-root Certificate
Template: EFSRecovery, EFS Recovery Agent
Cert Hash(sha1): 4d e5 b3 2e c7 94 2d 23 31 27 cb 3f 55 fa 0b 92 e9 c6 0e 6e
Key Container = d6d60d2163c8e2970602738b1de8c5fa_5f5cc49c-de6b-442e-a698-c10048765884
Provider = Microsoft Base Cryptographic Provider v1.0
Encryption test passed
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.4.1.311.10.3.4.1 File Recovery
Certificate is valid
CertUtil: -verifystore command completed successfully.
Voici les informations d'un certificat déplacé. Dans un premier temps récupéré dans le contexte machine.
C:\>certutil –verifystore my
================ Certificate 3 ================
Serial Number: 14890a70000000000005
Issuer: CN=vpcw2k3ca, DC=vpcw2k3, DC=local
Subject: CN=Administrator, CN=Users, DC=vpcw2k3, DC=local
Certificate Template Name: EFSRecovery
Non-root Certificate
Template: EFSRecovery, EFS Recovery Agent
Cert Hash(sha1): 4d e5 b3 2e c7 94 2d 23 31 27 cb 3f 55 fa 0b 92 e9 c6 0e 6e
Key Container = d6d60d2163c8e2970602738b1de8c5fa_5f5cc49c-de6b-442e-a698-c10048765884
Provider = Microsoft Base Cryptographic Provider v1.0
No stored keyset property
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.4.1.311.10.3.4.1 File Recovery
Certificate is valid
CertUtil: -verifystore command completed successfully.
Subject Alternative Name
Il peut parfois être nécessaire d'avoir plusieurs noms dans un même certificat. Par exemple quand deux noms différents peuvent être utilisés pour accéder à la même machine. Imaginons le cas particulier d'un serveur web accédé depuis l'intranet avec un nom du type webserver.mycompany.intra et depuis l'extérieur avec un nom du type www.mycompany.com. Il faudra alors mettre ces deux noms dans le certificat. Pour cela, on va utiliser un champ supplémentaire nommé "Subject Alternative Name".
Il faut donc configurer l'autorité de certification pour activer cette extension, puis, dans la demande, remplir ce champ. La configuration de la CA se fait en ligne de commande, cette opération n'est à réaliser qu'une seule fois et est décrite dans l'article technique suivant
931351 How to add a Subject Alternative Name to a secure LDAP certificate
https://support.microsoft.com/default.aspx?scid=kb;EN-US;931351
C:\>certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
C:\>net stop certsvc
C:\>net start certsvc
Nous verrons plus loin, dans la partie demande de certificat comment renseigner ce champ.
Les méthodes de demande de certificat
Pour demander un certificat, plusieurs pré-requis sont nécessaires.
- Le contexte de sécurité utilisé pour faire la demande, doit avoir le droit de demander un certificat à la CA.
- Le contexte de sécurité utilisé pour faire la demande, doit avoir le droit de demander un certificat du modèle souhaité.
Permissions
Sur la CA, les permissions se consultent dans la console Certification authority, dans les propriétés de la CA, onglet security.
Pour le modèle de certificat, c'est dans les propriétés du modèle de certificat, onglet sécurité.
Authenticated users incluant les machines et les utilisateurs, c'est la façon la plus simple de permettre la distribution de certificat à tout le monde.
Par la console certificat
Cette demande utilise le contexte de sécurité de la machine. Il faut donc que le compte ordinateur ait le droit de demander des certificats à la CA, et ait le droit de demander des certificats des modèles désirés.
Sur le serveur, on démarre une mmc (démarrer / exécuter / mmc.exe) puis on charge le composant logiciel enfichable certificat pour le compte ordinateur. Dans la console ainsi ouverte, on effectue une demande de certificat à partir du magasin personnel.
On utilise alors le modèle RDS Server et on spécifie les noms à insérer dans le certificat. Le champ Subject Name est assez explicite, le champ Alternative name servira à alimenter l'extension Subject Alternative name du certificat.
Par la page web
Si vous avez installé le rôle Certification Authority Web Enrollment, vous pouvez réaliser cette même demande depuis la page web. Par défaut, celle-ci est accessible via https://<serveur>/certsrv
Depuis la page d'accueil, on sélectionne "Request a certificate" puis "Submit an advanced certificate request" et enfin "Create and submit a request to this CA"
On choisit le modèle de certificat désiré (ici RDS Server). Dans le champ Name, on saisit le subject Name. Dans le champ Attributes de la section Additionnal Options, on saisit
san:dns=<DNS name> [&dns=<DNS name>]
Cette opération, réalisée dans le contexte de sécurité de l'utilisateur, crée la clé privée et le certificat dans le magasin utilisateur. Il convient donc suivre la procédure décrite au paragraphe "Clés exportables" pour les copier dans le magasin de l'ordinateur.
En ligne de commande
Dans un fichier texte, on va définir les informations nécessaires à la demande de certificat.
Pour mon exemple, voici le fichier request.inf
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=vpcw2k8r2pdc.vpcw2k8r2.local"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1 ; Key Exchange
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate = RDSServer
SAN="dns=RDSFarm.vpcw2k8r2.local"
Ensuite, en utilisant l'outil certreq.exe, cette demande va être convertie en un format binaire.
C:\temp>certreq.exe -new request.inf request.req
Active Directory Enrollment Policy
{6EC1EAFF-EC09-47AD-A2D4-31391828E67A}
ldap:
DumpVariantStringWorker: 0: "Microsoft RSA SChannel Cryptographic Provider"
DumpVariantStringWorker: 1: "Microsoft DH SChannel Cryptographic Provide
Il est ensuite à soumettre à l'autorité de certification
C:\temp>certreq.exe -submit request.req request.cer
Active Directory Enrollment Policy
{6EC1EAFF-EC09-47AD-A2D4-31391828E67A}
ldap:
Il vous sera demandé quelle autorité de certification solliciter
RequestId: 12
RequestId: "12"
Certificate retrieved(Issued) Issued
Enfin, il faut enfin insérer le certificat reçu dans le magasin de la machine
C:\temp>certreq -accept request.cer
Le certificat est désormais présent dans le magasin Personal de l'ordinateur et sa clé privée est exportable.
Par la console IIS
Si la console IIS est installée sur le serveur il est possible de l'utiliser pour demander un certificat. Celle-ci est cependant limitée au sens où elle ne permet que de demander des certificats de type WebServer, impose de remplir tous les champs et ne donne pas accès au champ Subject Alternative Name. Par contre, la clé privée générée est exportable.