Les modèles de certificats

I. Présentation

Disponibles uniquement sur une autorité de type Enterprise, les modèles de certificats permettent de fixer bon nombre de paramètres qui s'appliqueront lors de l'émission du certificat, tels que :

• La longueur de la clé privée,
• La possibilité d'exporter la clé privée,
• La durée de vie du certificat.
• Etc.

La gestion des modèles de certificats s'effectue à l'aide de la console Autorité de certification.

II. Description

A. Modèles par défaut

Une liste de modèles prédéfinis est disponible lors de l'installation du rôle d'autorité. La plupart d'entre eux nécessitent une mise à niveau avant d'être publiés. Il faut pour cela dupliquer le modèle afin de créer un modèle personnalisé. Extrait :

B. Modes de compatibilité

L'activation de fonctionnalités supplémentaires dans les modèles passent par les modes de compatibilité.

Pour bien se rendre compte des possibilités débloquées en choisissant un mode de compatibilité supérieur, je les ai synthétisées dans un tableau.

Fixer un mode de compatibilité pour une version supérieure peut empêcher un système plus ancien d'obtenir un certificat depuis ce même modèle. Par exemple, un mode de compatibilité Windows Server 2016 ne permettra pas à un serveur fonctionnant sous Windows Server 2012 d'obtenir un certificat.

III. Création de modèles personnalisés

Afin de créer un nouveau modèle, il convient de s'appuyer sur un modèle existant et d'apporter des modifications à sa configuration.

Depuis la console de gestion de l'autorité de certification, à la rubrique "Modèles de certificats", faites un clic-droit "Gérer". Une nouvelle fenêtre avec la liste des modèles s'ouvre.

Sélectionnez un modèle existant, ici « Serveur Web », puis réalisez un clic-droit, "Dupliquer le modèle".

Ici, il convient de fixer le mode de compatibilité en fonction de la version du système de l'autorité et de la version du système destinataire (poste client ou serveur).

Pour les noms de modèles, je vous recommande d'établir une convention de nommage en indiquant :

• Un préfixe,
• L'usage du certificat,
• La longueur de clé,
• Une version de modèle.

On peut aussi imaginer intégrer la durée ou le fait que la clé est exportable ou non.

Il faut également spécifier la "durée de validité", et la fenêtre de "renouvellement" du certificat, particulièrement utile si l'inscription automatique (autoenrollment) est activée.

La case "Publier le certificat dans Active Directory" ne sert pas à publier le modèle, contrairement à ce que le plus grand nombre croit, mais elle permet d'injecter la partie publique du certificat sur l'objet Active Directory destinataire : compte utilisateur ou ordinateur. Cela n'est utile que lors de scénario impliquant du chiffrement, par exemple, d'e-mails, ou quand un échange de clé publique est nécessaire entre l'expéditeur et le destinataire.

Sur l’écran suivant, il est possible d’indiquer si la clé privée du certificat est exportable ou non. Permettre l’export de la clé est particulièrement utile si un même certificat doit être installé sur plusieurs machines ou en cas de migration.

Le renouvellement du certificat en conservant la même clé peut sembler intéressant, cela étant, je recommande de profiter du renouvellement pour changer également la clé privée pour des questions de sécurité.

Au point n°1 on indique le fournisseur cryptographique, soit de type KSP, soit de type hérité (Legacy). Le choix à privilégier est KSP, c’est-à-dire "Fournisseur de stockage de clés".

Parmi les algorithmes de chiffrement, RSA reste une valeur sûre, car suffisamment sécurisé et compatible partout. Parmi la liste, vous trouverez également ECDSA qui représente Elliptic Curve. Cet algorithme est intéressant, mais il n’est pas supporté sur toutes les versions de système d’exploitation.

Au point n°2, on trouve la longueur de clé, 2048 bits pour du RSA minimum, elle peut être de 256 bits en ECDSA.

Au point n°3, il nous faut choisir l’algorithme de hachage. SHA256 est le minimum (SHA1 est déprécié).

La rubrique "Conditions d'émission", au travers de la première option « Approbation », peut exiger qu’un administrateur de l’autorité valide la délivrance du certificat avant qu’il ne soit émis. La demande est alors visible à la rubrique « Demandes en attente » depuis la console de gestion de l’autorité.

Concernant la seconde option, il est possible d’exiger que la demande soit signée au travers d’un autre certificat.

L’onglet "Modèles obsolètes" offre la possibilité d'inclure des modèles remplacés. L'intérêt est notable lors du renouvellement d'un certificat. Si le poste dispose d'un certificat issu de l'ancien modèle, il saura qu'il doit obtenir un nouveau certificat en se basant sur le nouveau modèle.

Sauf besoins particuliers, les stratégies présentes dans l'onglet "Extensions" n'ont pas besoin d'être modifiées.

L'onglet "Sécurité" indique les utilisateurs ou les groupes habilités à :

• Contrôle total : modifier les propriétés du modèle, changer les permissions
• Lecture : lire les propriétés d'un modèle
• Ecriture : modifier le modèle (hors permissions)
• Inscrire : demander un certificat issu du modèle
• Inscription automatique : récupérer automatiquement un certificat issu du modèle (autoenrollment)

Au point 1, on observe que le groupe « Ordinateurs du domaine » (Domain Computers) possède un droit de Lecture et Inscrire, suffisant pour la délivrance manuelle d'un certificat.

Au point 2, vous constaterez que le compte admin qui a généré le nouveau modèle est automatiquement ajouté dans les permissions. Cela n'a aucune utilité puisqu'il est déjà couvert par Administrateurs du domaine (Domain Admins). Il doit être retiré en le sélectionnant et en cliquant sur Supprimer (point 3). Autrement cela est considéré comme une anomalie de sécurité.

La bonne pratique indique de positionner des droits en s'appuyant sur des groupes. Notez bien que les groupes en question doivent obligatoirement être de type Global ou de type Universel. En effet, les informations des certificats sont stockées dans la partition Configuration de l'AD.

Important : dans les permissions, il faut toujours veiller à ce que l'autorité dispose des permissions pour lire le modèle, sinon vous vous exposez à une erreur 0x800 lors de la demande. Ce droit est contenu dans Utilisateurs authentifiés (Authenticated Users) par défaut. Si vous souhaitez le retirer, il conviendra d'ajouter directement le compte ordinateur de l'autorité avec un droit de lecture.

Le mécanisme "Attestation de clé" offre la possibilité de valider que la clé privée a été émise correctement, par exemple, via un mécanisme tiers. Plus concrètement, on peut exiger que la clé privée soit protégée par une puce TPM.

L'onglet "Nom du sujet" indique si les informations de nom d'objet intégrées au certificat délivré sont récupérées depuis l'AD ou fournies dans la requête. D'un point de vue sécurité, il est recommandé d'éviter les modèles où il est possible de fournir les informations dans la demande, puisque n'importe quel nom d'objet pourrait y être injecté.

Dans certains cas, il est difficile de l'interdire, aussi, il faut veiller à ce que les droits sur le modèle soient restreints à un petit nombre d'utilisateurs ou de machines.

Si la case est activée, lors du renouvellement automatique du certificat, aucune information ne sera demandée, les mêmes noms qu'au moment de la génération seront utilisés.

Pour terminer, la partie "Serveur", qui permet d'éviter le stockage des certificats dans la base de l'autorité, ce qui peut avoir du sens pour des certificats temporaires, très courts en durée de vie.

IV. Publication

Maintenant que notre modèle est prêt, il peut être rendu disponible en le publiant. Depuis la console de gestion de l'autorité, faites un "clic-droit", "Nouveau", "Modèle de certificat à délivrer".

Dans la liste, sélectionnez le nouveau modèle, puis validez par "OK". Si le modèle n'apparait pas dans la liste, c'est que l'information n'a pas été répliquée d'un point de vue Active Directory. Il faut, en effet, que tous les contrôleurs de domaine aient répliqué l'information avant que le modèle puisse être publié.

Vous devriez obtenir un résultat similaire à celui-ci :

À savoir : un modèle personnalisé de certificat ne peut pas être visible sur le portail web de l'autorité. En effet, la version du schéma, au travers de l'attribut « msPKI-Template-Schema-Version », passe à 3. Or, le portail web, ne prend pas en charge les modèles avec des exigences supplémentaires lors de l'inscription. Seules les versions 1 et 2 sont compatibles.

Rien d'alarmant toutefois, car vous l'aurez compris au travers des chapitres précédents, le portail web n'est qu'une méthode parmi d'autres pour obtenir un certificat.

V. Conclusion

Vous savez désormais comment créer un nouveau modèle et vous disposez des recommandations nécessaires pour le faire en respectant les bonnes pratiques. Dans les prochains chapitres de ce cours, nous verrons comment obtenir un certificat issu d'un modèle, manuellement ou automatiquement.