AD CS CEP/CES : corriger « Certificate types are not available » lors de l’auto‑inscription

Après passage de l’annuaire AD (LDAP) vers CEP/CES, l’assistant d’inscription affiche « Certificate types are not available ». Ce guide opérationnel détaille les vérifications, tests et correctifs pour rétablir l’auto‑inscription AD CS sans reconstruire toute la PKI.

Sommaire

Comprendre l’erreur « Certificate types are not available » avec AD CS CEP/CES

Ce message apparaît lorsque le client ne reçoit aucun modèle de certificat depuis le serveur de stratégie (CEP). Dans votre contexte, le comportement est apparu juste après avoir remplacé le fournisseur LDAP par l’URL CEP :

https://&lt;IP‑PKI&gt;:50000/ADPolicyProvider_CEP_Kerberos/service.svc/CEP

Avec la configuration par défaut (stratégie Active Directory), les modèles sont listés. En passant par CEP/CES, la chaîne de décision inclut IIS, Kerberos (ou autre schéma d’authent), droits sur la CA et publication des modèles. La moindre rupture (SPN, délégation, autorisations, certificat serveur, inspection SSL, etc.) peut conduire CEP à renvoyer une liste vide et donc à l’erreur affichée par l’assistant.

Architecture fonctionnelle en bref

Pour fixer les idées :

[Client] --(Kerberos/HTTPS)--> [CEP: Enrollment Policy Web Service]
                               --(DCOM/Kerberos)--> [CES: Enrollment Web Service] --(DCOM/RPC)--> [AD CS (CA)]
                               --(LDAP/GC)--> [AD DS: modèles, NTAuth, AIA/CDP]

CEP expose les stratégies (quels modèles sont autorisés pour l’appelant).
CES soumet la demande à la CA au nom de l’appelant.
AD DS héberge les objets « Certificate Templates », le conteneur NTAuth et les emplacements AIA/CDP.

Symptômes typiques

Assistant « Certificate Enrollment » : texte « Certificate types are not available » et aucune carte de modèle.
Auto‑inscription silencieuse qui ne crée plus de certificats sur des postes auparavant conformes.
Journaux Microsoft‑Windows‑CertificateServices‑Client* (poste) et AD CS Enrollment Web Services (serveur) contenant des codes 401/403/500 ou des échecs Kerberos.

Axes de contrôle prioritaires

Axe de contrôle	Points clés à confirmer
Chaîne d’approbation	Le certificat racine et la CRL sont publiés (AIA/CRT, NTAuth) et présents sur les clients.
Accessibilité CEP/CES	URL valide, certificat SSL correspondant au FQDN (éviter l’IP). Port ouvert (idéalement 443) et aucune inspection SSL intermédiaire.
Authentification Kerberos	SPN « HTTP/<FQDN>[ :<port>] » enregistré sur le compte de service CEP/CES. Délégation Kerberos activée si compte dédié.
Autorisations	Sur les modèles : Read, Enroll et Autoenroll pour les groupes cibles. Sur la CA : droits requis pour le compte CEP/CES.
Stratégie de groupe	GPO « Certificate Services Client – Auto‑Enrollment » activée et liée aux OU correctes. Politique d’inscription pointant vers CEP.
Journaux & réseau	Analyse des journaux CertificateServices‑Client et AD CS Enrollment Web Services. Pas de blocage pare‑feu/proxy, résolution DNS correcte.

Procédure de diagnostic pas à pas

Vérifier la chaîne d’approbation et NTAuth

Sur un client affecté :

certutil -enterprise -viewstore Root
certutil -enterprise -viewstore NTAuth
certutil -pulse

Le certificat racine de la PKI doit être dans Trusted Root Certification Authorities.
La CA émettrice utilisée par CES doit être publiée dans le conteneur NTAuthCertificates. Sinon, publiez‑la depuis la CA : certutil -dspublish -f "C:\<chemin>\<CA_issuer.cer>" NTAuthCA

Valider CEP/CES et le certificat serveur

Évitez absolument l’IP dans l’URL : utilisez le FQDN couvert par le certificat IIS. Testez la connectivité et la négociation HTTP :

Test-NetConnection pki.contoso.com -Port 50000
Invoke-WebRequest -Uri https://pki.contoso.com:50000/ADPolicyProvider_CEP_Kerberos/service.svc/CEP `
  -UseDefaultCredentials -Method Get -SkipCertificateCheck:$false -Verbose

Attendus : code HTTP 200/401 (auth), jamais 403/500. Un 401 suivi d’un WWW-Authenticate: Negotiate est normal si l’URL est interrogée sans le client d’inscription.

Contrôler SPN et délégation Kerberos

Si l’application pool CEP/CES tourne sous un compte de domaine dédié (recommandé), vérifiez et corrigez les SPN :

setspn -Q HTTP/pki.contoso.com
setspn -Q HTTP/pki.contoso.com:50000

rem Si absent, enregistrez-les sur le compte de service :
setspn -S HTTP/pki.contoso.com CONTOSO\svc_ces
setspn -S HTTP/pki.contoso.com:50000 CONTOSO\svc_ces

Puis configurez la délégation contrainte Kerberos sur le compte CONTOSO\svc_ces :

ADUC → compte svc_ces → onglet Délégation.
Choisir « Seuls les services spécifiés », « Kerberos uniquement ».
Ajouter l’ordinateur de la CA (service HOST/RPCSS du serveur CA).

Si vous utilisez l’identité machine de l’IIS (ApplicationPoolIdentity), déclarez les SPN sur le compte ordinateur de votre serveur web, ou désactivez Kernel-mode pour l’authentification Windows et activez useAppPoolCredentials si approprié.

appcmd set config -section:system.webServer/security/authentication/windowsAuthentication `
  /useKernelMode:false /commit:apphost
appcmd set config -section:system.webServer/security/authentication/windowsAuthentication `
  /useAppPoolCredentials:true /commit:apphost

Après modification des SPN, videz le cache Kerberos côté client :

klist purge
gpupdate /force

Paramétrer correctement IIS pour CEP/CES

Bindings HTTPS : type HTTPS, Host name = FQDN, certificat serveur avec SAN (FQDN), SNI activé si partagé.
Authentification : Windows Authentication activée (fournisseur Negotiate en premier), Anonymous désactivée pour CES/CEP Kerberos.
Reverse‑proxy/SSL inspection : à proscrire. Ajoutez une exception/bypass pour pki.contoso.com.
Pool d’applications : identité = compte de service dédié ou identité machine, mais jamais un compte sans droits sur la CA.

Vérifier GPO et cible (utilisateur vs ordinateur)

Deux paramètres clés sous Public Key Policies :

Certificate Services Client – Certificate Enrollment Policy : ajoutez un point URL vers votre CEP (auth Kerberos). Définissez‑le comme Stratégie par défaut. Configurez à la fois la portée Ordinateur et/ou Utilisateur selon les modèles visés.
Certificate Services Client – Auto‑Enrollment : Enabled + cocher « Renouveler les certificats expirés, mettre à jour les certificats en attente et retirer les certificats révoqués » ainsi que « Mettre à jour les certificats qui utilisent des modèles de certificats ».

Assurez-vous que la GPO est liée aux OU contenant les objets ciblés (postes pour modèles ordinateur, utilisateurs pour modèles utilisateur), et que le filtrage de sécurité autorise l’application (Auth. Users + cible ou groupes précis). Sur un client :

gpresult /h C:\gp.html
start C:\gp.html

Contrôler modèles et autorisations

Dans certtmpl.msc, ouvrez chaque modèle attendu → onglet Security → confirmez Read + Enroll (et Autoenroll si auto‑inscription) pour les groupes cibles (Domain Computers, groupes métier, etc.).
Vérifiez l’onglet Compatibility du modèle (OS mini client/CA). Des réglages trop restrictifs peuvent invisibiliser le modèle.
Dans certsrv.msc (sur la CA) → Certificate Templates → le modèle doit être publié. À défaut, l’ajouter.

Vous pouvez lister côté client ce que CEP renvoie réellement :

Get-Certificate -Url &quot;https://pki.contoso.com:50000/ADPolicyProvider_CEP_Kerberos/service.svc/CEP&quot; `
  -PolicyServer -Context User -Verbose

Si la liste retournée est vide, c’est que CEP filtre tout (souvent à cause des droits, de l’authentification ou d’un échec d’accès AD/CES).

Droits de CES sur la CA

Le compte d’exécution de CES doit pouvoir dialoguer en DCOM avec la CA et « demander des certificats » au nom du requérant.

Sur le serveur CA : ajoutez le compte CES au groupe local Certificate Service DCOM Access.
Dans certsrv.msc → clic droit CA → Properties → onglet Security → autorisez Read + Request Certificates (ou Enroll selon version) pour le compte CES.

DNS, pare‑feu et MTU

DNS : résout le FQDN du site IIS vers la bonne IP. Évitez les CNAME chaînés qui cassent SNI/host header.
Pare‑feu : ouvrez 443 (recommandé) ou 50000 selon votre design, ainsi que les flux CES→CA (RPC/DCOM dynamiques, TCP 135 + plage éphémère restreinte si possible).
Inspection SSL/HTTP : à désactiver pour le FQDN PKI.

Lecture des journaux

Emplacement	À surveiller
Client → Applications and Services Logs\Microsoft\Windows\CertificateServices‑Client*	Événements d’auto‑inscription, détail des modèles refusés, codes erreurs WinHTTP/Kerberos.
Serveur CEP/CES → Applications and Services Logs\AD CS Enrollment*	Échecs d’authentification (401), interdictions (403), erreurs DCOM vers la CA.
Serveur CA → Security / Application	Accès DCOM refusés, autorisations CA insuffisantes, erreurs de publication CRL/AIA.
IIS → Logs W3SVC	Traces de la négociation (401→200), en‑têtes WWW‑Authenticate, temps de réponse.

Correctifs par scénarios fréquents

URL avec IP ou certificat serveur non concordant

Symptôme : l’authentification Kerberos ne s’établit pas, NTLM s’impose, la délégation échoue et CEP renvoie zéro modèle.

Correctif : utilisez le FQDN dans l’URL CEP/CES, regénérez le certificat IIS avec SAN adéquat et remplacez la configuration GPO. Exemple d’URL :

https://pki.contoso.com/ADPolicyProvider_CEP_Kerberos/service.svc/CEP

SPN manquant ou dupliqué

Symptôme : 401 en boucle, événements Kerberos (KRB_AP_ERR_MODIFIED), parfois succès via NTLM mais délégation impossible.

Correctif : corriger les SPN comme montré plus haut et supprimer les doublons (setspn -X pour détecter).

Délégation Kerberos non autorisée

Symptôme : authentification côté CEP OK, mais impossibilité de soumettre la requête à la CA au nom de l’appelant.

Correctif : activer la délégation contrainte du compte CES vers l’ordinateur de la CA.

Modèles non publiés ou droits insuffisants

Symptôme : via LDAP tout semblait OK (héritage de droits), mais via CEP les contrôles sont stricts et filtrent tous les modèles.

Correctif : publier les modèles sur la CA et accorder Read/Enroll/Autoenroll aux bons groupes.

CA non présente dans NTAuth

Symptôme : le client refuse d’accepter les certificats émis par cette CA pour l’authentification.

Correctif : publier la CA dans NTAuth (commande certutil -dspublish ... NTAuthCA).

Proxy ou inspection SSL

Symptôme : codes 502/403, altérations TLS, listes vides côté CEP.

Correctif : exclure le FQDN PKI de tout proxy/inspection TLS.

Droits CES sur la CA

Symptôme : erreurs DCOM, 500 côté CES, aucun modèle proposé.

Correctif : ajouter le compte CES à Certificate Service DCOM Access et accorder Read + Request Certificates sur la CA.

Étude de cas : reconstruction de la PKI et résolution immédiate

Dans le scénario que vous avez rencontré, tous les axes de contrôle paraissaient conformes, mais l’assistant affichait toujours « Certificate types are not available ». La reconstruction d’une nouvelle instance AD CS a immédiatement rétabli l’auto‑inscription via CEP/CES. Cela indique avec une forte probabilité :

un état corrompu du magasin de la CA (ACL, DCOM, SDDL altérée, entrée NTAuth obsolète),
ou des méta‑données de modèles incohérentes dans AD (SIDs orphelins, héritage bloqué),
ou une mauvaise identité du pool IIS (compte modifié, SPN non mis à jour),
ou une collision de SPN non détectée lors d’un renommage/alias.

Leçon : avant d’en arriver à la reconstruction, un export/compare des ACL et des objets critiques (CA, templates, NTAuth, SCP CEP/CES) facilite l’isolement de la divergence.

Check‑list « 5 minutes »

URL CEP en FQDN, pas d’IP, certificat IIS valide.
SPN HTTP/<FQDN>[:port] présents sur le bon compte. Pas de doublon.
Délégation contrainte activée de CES vers la CA.
GPO Auto‑Enrollment activée + Enrollment Policy pointant CEP.
Modèles publiés sur la CA avec droits Read/Enroll/Autoenroll corrects.
CA publiée dans NTAuth, CRL/AIA accessibles.
Aucun proxy/inspection TLS entre client et CEP/CES.

Scripts et commandes utiles

Déclencher l’auto‑inscription et voir l’état

certutil -pulse
whoami /user
klist

Lister ce que CEP publie (vue utilisateur ou ordinateur)

# Vue Utilisateur
Get-Certificate -PolicyServer -Context User `
  -Url "https://pki.contoso.com/ADPolicyProvider_CEP_Kerberos/service.svc/CEP" -Verbose

# Vue Ordinateur (exécuter en PowerShell admin sur la machine)

Get-Certificate -PolicyServer -Context Machine `
-Url "[https://pki.contoso.com/ADPolicyProvider_CEP_Kerberos/service.svc/CEP](https://pki.contoso.com/ADPolicyProvider_CEP_Kerberos/service.svc/CEP)" -Verbose

Inspecter les modèles publiés sur la CA

certutil -catemplates

Exporter les objets de modèles pour audit

ldifde -f C:\PKI_Templates.ldf -d &quot;CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com&quot;

Sauvegardes minimales de la CA

certutil -backup C:\BackupCA
certutil -backupKey C:\BackupCA
reg export &quot;HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration&quot; C:\BackupCA\CA_Config.reg

Bonnes pratiques de conception et d’exploitation

Port : privilégiez 443. Si un port personnalisé est imposé, faites la réécriture en frontal (reverse‑proxy/NAT) plutôt que de modifier CEP/CES.
Points de terminaison : ajoutez un endpoint anonyme ou basé comptes si vous devez gérer des machines hors domaine (attention au périmètre de droits).
Surveillance : conservez les journaux d’inscription, mettez en place des rapports hebdomadaires (nombre d’échecs, modèles impactés). Un pic d’échecs précède souvent un incident majeur.
Plan de sauvegarde PKI : export régulier de la clé privée de la CA, des modèles (LDIF), de la configuration IIS et des ACL CA. Testez la restauration en pré‑production.
Séparation des rôles : CEP/CES sur hôtes dédiés, comptes de service distincts, moindres privilèges, mots de passe gérés.
Tolérance aux pannes : AIA/CDP hautement disponibles (HTTP), CRL delta si nécessaire, surveillance d’expiration.

Plan de remédiation recommandé

Corriger l’URL CEP pour utiliser le FQDN + certificat IIS valide.
Assainir SPN et activer la délégation du compte CES vers la CA.
Valider GPO (policy + auto‑enrollment) et portée (OU cibles).
Revoir les modèles (droits, compatibilité, publication sur CA).
Vérifier NTAuth/AIA/CDP et publication CRL.
Tester avec Get-Certificate (User/Machine) et certutil -pulse.
Si l’état reste incohérent, comparer ACL/SDDL de l’ancienne instance avec une instance témoin saine pour détecter une corruption.

FAQ éclair

CEP vs CES ? CEP détermine ce que l’on peut demander (liste des modèles), CES effectue la demande à la CA au nom de l’appelant.

Pourquoi LDAP fonctionnait‑il encore ? En mode LDAP, le client lit directement AD. En mode CEP/CES, toute incohérence d’IIS/Kerberos/CA peut filtrer tous les modèles.

Peut‑on laisser le port 50000 ? Oui, mais par simplicité et sécurité, 443 (TLS standard) + réécriture en frontal est préférable.

Conclusion

L’erreur « Certificate types are not available » n’est pas une fatalité. En traitant méthodiquement l’URL (FQDN + certificat), les SPN/délégations Kerberos, les GPO, les droits sur modèles/CA et l’accessibilité réseau, vous rétablirez la liste des modèles via CEP. Le cas où une reconstruction « guérit » tout révèle généralement une configuration ou des ACL corrompues : d’où l’importance d’auditer et de sauvegarder régulièrement la PKI.

Annexes pratiques

Exemple de configuration GPO (texte)

Computer Configuration
  Policies\Windows Settings\Security Settings\Public Key Policies
    - Certificate Services Client - Certificate Enrollment Policy
        Policy: &quot;CEP - Production&quot; (Default)
        URL   : https://pki.contoso.com/ADPolicyProvider_CEP_Kerberos/service.svc/CEP
        Auth  : Integrated (Kerberos)
    - Certificate Services Client - Auto-Enrollment
        State : Enabled
        Options: Renew expired, update pending, remove revoked
                 Update certificates that use certificate templates
User Configuration
  (mêmes paramètres si vous déployez des modèles Utilisateur)

Modèle de journal à surveiller (client)

Log: Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational
Filtres utiles:
  - Task Name: Autoenrollment
  - Level: Warning, Error
  - Keywords: Enrollment, Policy, Template, CEP, CES, Kerberos

Commandes de santé CEP/CES (serveur)

# Redémarrer IIS après changement d’authentification/bindings
iisreset

# Tester l’identité du pool (échantillon)

whoami
klist

# Vérifier l’accès DCOM vers la CA (depuis le serveur CES)

certutil -config - -ping

Conseils de durcissement

Désactiver les suites TLS obsolètes et imposer TLS 1.2+.
Restreindre la plage de ports DCOM et la publier explicitement sur le pare‑feu.
Journaliser l’accès IIS (W3C) et expurger régulièrement avec rétention conforme.

Informations complémentaires utiles

Port personnalisé : sauf contrainte précise, privilégiez le port 443 et, si nécessaire, réécrivez le port en frontal (reverse‑proxy, NAT) plutôt que de modifier CEP/CES.
Points de terminaison CEP/CES : ajoutez un endpoint anonyme ou basé comptes si vous gérez des machines hors domaine.
Surveillance continue : conservez les journaux d’inscription et planifiez des rapports pour détecter rapidement les échecs de modèles.
Plan de sauvegarde PKI : exportez régulièrement la clé privée de la CA, les modèles et la configuration IIS afin d’éviter une reconstruction totale en cas de panne future.

Rappel critique : si le moindre doute existe sur SPN/délégation, n’utilisez jamais une URL avec adresse IP, et préférez un certificat IIS dédié au FQDN de service CEP/CES.

Astuce opérationnelle : pour valider qu’un modèle est vraiment proposé par CEP, utilisez Get-Certificate -PolicyServer (User/Machine). S’il n’apparaît pas, inutile d’insister côté GPO : la cause est en amont (auth/droits).