Concevoir des modèles AD CS pour les rôles de passerelle VPN et de client

Une AC d'entreprise peut émettre tous les certificats dont un VPN a besoin sans jamais être elle-même la passerelle. Le travail de conception consiste à décider ce que chaque pair doit prouver, puis quel modèle peut émettre une accréditation qui prouve exactement cela. Je commence par une table des rôles, je duplique un modèle adapté plutôt que d'en modifier un sur place, je fixe la source du sujet par rôle, je publie le résultat sur l'AC émettrice et j'inscris un pilote avant que quiconque l'automatise. Chaque étape ci-dessous est un endroit où une AC qui fonctionne produit encore un certificat que le VPN rejettera.

Écrivez la table des rôles avant d'ouvrir la console des modèles

Deux rôles, deux usages. La passerelle prouve une identité de service, donc son certificat a besoin de Server Authentication (1.3.6.1.5.5.7.3.1), d'un usage de clé de signature numérique et de chiffrement de clé, et du nom d'hôte que les clients contactent dans un autre nom du sujet. Les clients qui s'authentifient par certificat ont besoin de Client Authentication (1.3.6.1.5.5.7.3.2) et d'une identité qui corresponde à ce que la passerelle attend dans son contrôle du pair. Un certificat utilisateur et un certificat d'ordinateur ne sont pas interchangeables, car ils vivent dans des magasins différents et sont utilisés par des processus différents.

Notez quatre colonnes par rôle : l'identité qui doit apparaître, l'usage, le consommateur de la clé et si la clé peut quitter la machine. Cette table décide ensuite chaque case à cocher, et c'est aussi ce que vous remettez à un relecteur. L'authentification des clients par mot de passe est une branche distincte : si la passerelle authentifie les utilisateurs par identifiants, distribuer des certificats clients ajoute du travail sans ajouter de preuve.

Dupliquez un modèle au lieu de modifier un modèle partagé

Partez d'un modèle dont l'usage est à peu près correct, par exemple RAS and IAS Server pour la passerelle ou Computer pour les appareils joints au domaine, puis dupliquez-le et donnez à la copie un nom qui dit à quoi elle sert. Élargir un modèle que d'autres services utilisent déjà est la modification qui casse quelque chose sans rapport six semaines plus tard. Sur la copie, réglez les stratégies d'application sur l'usage de la table des rôles, gardez l'usage de clé cohérent avec lui, choisissez l'algorithme et la longueur de clé que vos passerelles acceptent, et marquez la clé privée comme non exportable sauf si un équipement a besoin de l'exporter pour la déplacer.

La validité et le renouvellement appartiennent aussi au modèle. Une durée courte est plus facile à révoquer et plus difficile à exploiter ; une durée longue réduit le travail d'inscription et allonge l'exposition d'une clé divulguée. Choisissez un nombre que vous pouvez défendre, et notez que la validité propre de l'AC et la période de renouvellement du modèle peuvent raccourcir le résultat.

Décidez d'où vient le sujet

Pour un ordinateur ou un utilisateur de domaine, construisez le sujet à partir des informations de l'annuaire afin que le demandeur ne puisse pas saisir le nom. Pour une passerelle qui n'est pas jointe au domaine, ou un appareil dont l'identité est attribuée hors d'AD, le modèle a besoin à la place d'un chemin de demande contrôlé. Autoriser un sujet et des autres noms fournis par le demandeur est une vraie décision : ce n'est pas une licence permettant à chaque inscrit de revendiquer n'importe quel nom, et la stratégie côté AC doit encore dire qui peut demander et quelle preuve est exigée.

Windows IKEv2 est strict ici. Le certificat de la passerelle est comparé au nom que le client a configuré, donc le nom DNS doit être présent là où le client le cherche, généralement une entrée dNSName dans l'autre nom du sujet. Désactiver le contrôle du nom ou de l'usage pour faire fonctionner un certificat qui ne correspond pas supprime le contrôle qui aurait détecté l'incohérence en production.

Publiez le modèle, puis restreignez les autorisations

Créer l'objet de modèle dans AD DS et le publier sur l'AC émettrice sont deux opérations distinctes, effectuées dans des consoles différentes. Publiez la copie depuis la console Certification Authority sous Certificate Templates, puis vérifiez en ligne de commande que l'AC la propose désormais :

certutil -CATemplates
certutil -TCAInfo

Les autorisations viennent ensuite. Accordez Read et Enroll aux groupes qui doivent le demander et rien de plus, gardez l'accès en lecture de l'AC intact, et n'accordez Autoenroll que là où l'inscription automatique est voulue et soutenue par la stratégie de déploiement qui la fait fonctionner. Une case d'un modèle n'inscrit rien à elle seule, et un modèle publié sans autorisation d'inscription produit un portail qui liste le certificat puis refuse la demande.

Inscrivez un pilote dans le consommateur réel

Demandez le certificat dans le contexte qui l'utilisera, puis examinez ce qui est revenu au lieu de faire confiance au nom du fichier. Un certificat utilisateur atterrit dans le magasin de l'utilisateur courant et un certificat d'ordinateur dans celui de l'ordinateur local, et MMC montre les deux, c'est pourquoi une inscription qui “a fonctionné” peut rester invisible pour le service VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Lisez le vidage pour le sujet, les autres noms, l'usage amélioré de la clé et la chaîne. Pour une passerelle non Windows, soumettez la demande via le flux de travail pris en charge au lieu de supposer que l'inscription automatique du domaine l'atteint, et confirmez que le format exporté est celui que le consommateur importe avec sa clé privée correspondante. Enfin, gardez la confiance et l'autorisation séparées : le VPN doit encore décider quels utilisateurs ou appareils atteignent quelles ressources, et la révocation ne retire l'accès que si la passerelle vérifie la révocation. Le guide Microsoft de gestion des modèles de certificats couvre la console des modèles, les autorisations et l'étape de publication distincte.