⌚ Environ 2 min de lecture

Voir mes favoris

Limiter les autorités de certification autorisées tout en évitant de casser les renouvellements automatiques.

Avant de commencer

Travaillez sur une copie ou un test contrôlé lorsque l’action peut affecter la production. Conservez les horodatages, captures et l’ancienne configuration afin de comparer le résultat.

Étapes

Lister les autorités réellement utilisées pour les certificats du domaine.
Ajouter les entrées CAA issue et éventuellement issuewild adaptées.
Publier d’abord sur le domaine racine puis contrôler l’héritage sur les sous-domaines.
Interroger les CAA depuis plusieurs résolveurs et vérifier le TTL.
Lancer un renouvellement de test avant de rendre la politique plus restrictive.

Validation

Rejouez le test initial après la modification et confirmez que le service attendu fonctionne sans créer de nouvelle régression. Documentez l’état final.

Complément technique

PKI : émission CAA et usage LDAPS répondent à des contrôles différents

Repères techniques

CAA indique quelles autorités peuvent émettre pour un domaine ; il ne remplace pas la validation TLS côté client.
Pour LDAPS, le certificat du DC doit couvrir le FQDN utilisé et inclure une EKU Server Authentication adaptée.
LDAPS utilise typiquement TCP/636 ; la réussite du port ne prouve pas que le certificat présenté est le bon.

LDAPS

Lire le certificat réellement présenté par le contrôleur de domaine et vérifier SAN, EKU, dates et chaîne.

openssl s_client -connect dc01.example.local:636 -servername dc01.example.local -showcerts

Pièges spécifiques

Publier un CAA trop restrictif avant d’identifier toutes les autorités utilisées peut bloquer un renouvellement futur.
Avoir plusieurs certificats éligibles sur un DC peut conduire Schannel à en sélectionner un inattendu.

Comment valider

Le certificat LDAPS présenté est celui attendu et les clients lui font confiance.
Les CAA publiés autorisent explicitement les CA réellement utilisées par le domaine.

Preuves et vérifications

CAA indique quelles autorités peuvent émettre pour un domaine ; il ne remplace pas la validation TLS côté client. Pour LDAPS, le certificat du DC doit couvrir le FQDN utilisé et inclure une EKU Server Authentication adaptée.

Contrôle de résultat

Le certificat LDAPS présenté est celui attendu et les clients lui font confiance. Les CAA publiés autorisent explicitement les CA réellement utilisées par le domaine.

Point d’attention

Publier un CAA trop restrictif avant d’identifier toutes les autorités utilisées peut bloquer un renouvellement futur. LDAPS utilise typiquement TCP/636 ; la réussite du port ne prouve pas que le certificat présenté est le bon.

Concepts liés

Référence primaire : RFC 8659 — DNS CAA.