Certificats wildcard automatisés avec cert-manager et le défi DNS-01

Le défi HTTP-01 est simple à comprendre et suffit dans la plupart des cas. Il a cependant une limite rédhibitoire : il ne permet pas d’obtenir un certificat wildcard.

Dès qu’on gère une dizaine de sous-domaines, émettre un certificat par service devient une source de pannes récurrentes — celui qu’on a oublié de renouveler, celui dont la validation échoue parce que le service était momentanément injoignable.

Pourquoi DNS-01

Le défi DNS-01 prouve la maîtrise du domaine en créant un enregistrement TXT. Il ne nécessite aucune exposition publique du service, ce qui permet de couvrir des services internes, et c’est le seul mécanisme autorisant les wildcards.

Sa contrepartie : cert-manager doit disposer d’un accès en écriture à votre zone DNS. C’est un secret sensible, à traiter comme tel.

Le point de vigilance sur les droits

Les interfaces de programmation DNS accordent rarement des droits fins. Le jeton créé pour cert-manager peut souvent modifier bien plus que les enregistrements de validation.

Créez un compte dédié, restreint à la zone concernée, et jamais réutilisé pour autre chose. Si votre fournisseur permet de limiter les droits aux seuls enregistrements TXT, faites-le.

Émettre le certificat

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example-tls
  namespace: cert-manager
spec:
  secretName: wildcard-example-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - 'example.test'
    - '*.example.test'

Notez que le domaine racine est déclaré en plus du wildcard. Un certificat *.example.test ne couvre pas example.test, ni les sous-domaines de second niveau comme a.b.example.test.

Le vrai problème : diffuser le secret

Un secret Kubernetes est confiné à son espace de noms. Le certificat est émis dans celui de cert-manager, mais il doit être lisible par chaque ingress, dans chaque espace de noms applicatif.

Trois approches existent. Émettre un certificat par espace de noms multiplie inutilement les demandes auprès de l’autorité, laquelle applique des quotas. Autoriser la lecture inter-espaces affaiblit une isolation qu’on a mis du temps à construire.

La troisième consiste à recopier le secret vers les espaces de noms consommateurs, par une tâche planifiée ou un contrôleur dédié. C’est celle que je retiens : une seule émission, une isolation préservée, et une diffusion explicite et auditable.

Vérifier le renouvellement

Un certificat qui s’émet correctement une fois ne prouve rien. Ce qui compte, c’est le renouvellement automatique trente jours avant expiration — et la diffusion des copies après ce renouvellement.

Le piège classique est là : le certificat source est bien renouvelé, mais les copies ne le sont pas, et les services servent un certificat expiré alors que cert-manager déclare tout en ordre.

Supervisez la date d’expiration réelle du certificat servi par chaque ingress, et non l’état de l’objet Certificate. C’est la seule mesure qui reflète ce que voit l’utilisateur.