Vous êtes allés vérifier vos AC après le dernier post. Vous avez trouvé des modèles par défaut publiés. Maintenant il faut les remplacer. Trois étapes, dans l'ordre, avec un paramètre qui piège la plupart des gens.

1. Créez le remplacement.

Dupliquez le modèle par défaut. Réglez la compatibilité au plus haut niveau que vos vrais consommateurs peuvent utiliser. Limitez les EKU à ce dont ils ont vraiment besoin. Remplacez Utilisateurs authentifiés par un groupe de sécurité spécifique. Faites tous les changements que vous auriez voulu que le modèle par défaut ait.

2. Remplacez l'ancien (Superseded).

Sur le nouveau modèle, onglet Modèles remplacés, ajoutez l'original. Publiez le nouveau modèle sur l'AC. L'inscription automatique va router les nouvelles demandes vers le remplacement, et les détenteurs de certificats existants vont renouveler sur le nouveau modèle à leur cycle de renouvellement normal. Le PDF téléchargeable ci-dessus montre l'onglet Modèles remplacés sur le nouveau modèle, avec le modèle User par défaut ajouté.

3. Attendez, ou forcez les choses.

Si vous voulez aller plus vite que le cycle de renouvellement naturel, clic-droit sur le nouveau modèle dans certtmpl.msc et choisissez Réinscrire tous les détenteurs de certificats. Ça bumpe la version du modèle et déclenche la réinscription au prochain cycle d'inscription automatique. À utiliser avec parcimonie. Forcer la réinscription sur des milliers de certificats, c'est un DoS auto-infligé sur votre AC, surtout avec une émission adossée à un HSM. Le PDF téléchargeable ci-dessus montre où ça se trouve dans le menu contextuel (clic-droit).

Une fois la transition vérifiée, dépubliez l'ancien modèle.

Le paramètre qui piège tout le monde : la Compatibilité.

Un modèle de compatibilité « Windows Server 2016 » ne veut pas dire qu'un client plus ancien ne peut pas obtenir un certificat. Le certificat reste du X.509. Une machine XP va le recevoir sans problème.

Ce que le paramètre veut vraiment dire : le modèle peut utiliser des fonctionnalités qui demandent un support client moderne. Renouvellement basé sur la clé. Choix de CSP/KSP spécifiques. Si le client ne comprend pas ces fonctionnalités, il les ignore. Le certificat fonctionne quand même.

Donc choisissez la compatibilité la plus haute dont votre plus vieux vrai consommateur peut utiliser les fonctionnalités. Pas le plus vieux qui existe quelque part dans votre réseau.

Un point que le remplacement de modèle ne réglera pas.

Si vous avez des systèmes qui ne savent vraiment pas parler les protocoles cryptographiques modernes (SHA-1 seulement, TLS vétuste, suites de chiffrement anciennes), aucun paramètre de modèle ne va les sauver. C'est une autre conversation. Segmentation. Plan de remplacement. Contrôles compensatoires. Le nouveau modèle va leur émettre un certificat parfaitement moderne qu'ils ne peuvent ni valider ni utiliser.

La plupart des modèles par défaut peuvent être remplacés en un après-midi. Ceux qui ne peuvent pas ont généralement une histoire derrière eux. Savoir lesquels sont lesquels, c'est ça le vrai travail.

À quand remonte la dernière fois où vous avez forcé une réinscription, et qu'est-ce qui a brisé?

Du terrain

Il y a quelques années, j'ai forcé une réinscription sur un modèle User chez un client. Environ 12 000 certificats utilisateurs. L'AC adossée à un HSM en émettait encore 14 heures plus tard. J'ai eu l'appel d'après-shift de l'équipe réseau parce qu'on avait saturé la carte réseau de l'AC.

Maintenant je dis aux gens : si vous devez bumper la version, étalez ça par sous-ensembles de destinataires (filtrez par OU, par site, par groupe, choisissez quelque chose qui borne la vague) pour pas faire ce que j'ai fait.