Configurer DANE pour le SMTP : enregistrements TLSA et DNSSEC pour votre serveur mail

Ce que ça veut dire

Par défaut, les serveurs qui vous livrent des emails utilisent le TLS (STARTTLS) seulement « si possible », et ils ne vérifient pas votre certificat. Un attaquant sur le réseau pourrait supprimer le STARTTLS ou présenter un faux certificat. DANE pour le SMTP (RFC 7672) comble cette faille : vous publiez dans le DNS un enregistrement TLSA qui indique quel certificat ou quelle clé utilise votre serveur mail, et DNSSEC prouve que cet enregistrement est authentique. Les serveurs d'envoi compatibles DANE refusent alors de livrer sans un TLS valide et correspondant.

L'enregistrement TLSA d'un serveur mail est publié sur _25._tcp. suivi du nom d'hôte du MX :

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 8f1c...e4a2

Les trois nombres signifient : 3 = le certificat propre au serveur (DANE-EE), 1 = comparer uniquement la clé publique (pas tout le certificat), 1 = empreinte SHA-256. 3 1 1 est le choix habituel pour le SMTP.

DANE et MTA-STS résolvent le même problème de façons différentes. MTA-STS utilise le HTTPS et fonctionne sans DNSSEC ; DANE a besoin de DNSSEC. Vous pouvez publier les deux, et utiliser TLS-RPT (présenté dans le guide MTA-STS) pour recevoir des rapports sur les deux.

Pourquoi cela arrive

Vous mettez peut-être DANE en place parce que :

• un audit de sécurité, une règle publique ou sectorielle, ou un test de type internet.nl l'exige (fréquent aux Pays-Bas et en Allemagne) ;
• vous voulez protéger les emails entrants des attaques par rétrogradation (downgrade) ;
• un test DANE signale que votre enregistrement TLSA ne correspond plus après un renouvellement de certificat, ce qui fait que les expéditeurs compatibles DANE cessent de vous livrer.

Comment vérifier

1. DNSSEC : la zone du nom d'hôte de votre MX doit être signée. Avec dig, cherchez l'indicateur ad renvoyé par un résolveur qui valide :

   dig +dnssec MX yourdomain.com @1.1.1.1
   ;; flags: qr rd ra ad;

   Si le MX pointe vers l'hôte de votre prestataire (Google, Microsoft 365...), c'est leur zone qui a besoin de DNSSEC et du TLSA, pas la vôtre.
2. Enregistrement TLSA :

   dig +dnssec TLSA _25._tcp.mail.yourdomain.com

3. Comparez avec le certificat en service :

   openssl s_client -connect mail.yourdomain.com:25 -starttls smtp \
     -servername mail.yourdomain.com </dev/null 2>/dev/null \
     | openssl x509 -noout -pubkey \
     | openssl pkey -pubin -outform DER | openssl dgst -sha256

   L'empreinte doit être identique au dernier champ de l'enregistrement TLSA.
4. Outil Postfix : posttls-finger -t30 -T180 -c -L verbose,summary yourdomain.com indique si la validation DANE réussit.
5. Utilisez le scanner de domaine pour confirmer les noms d'hôte de vos MX avant de commencer.

Comment corriger

1. Activez DNSSEC

Activez DNSSEC chez votre hébergeur DNS, puis ajoutez l'enregistrement DS chez votre registrar (beaucoup le font automatiquement). Vérifiez avec le Whois quel registrar gère le domaine. Sans chaîne DNSSEC valide, les enregistrements TLSA sont ignorés.

2. Obtenez l'empreinte de la clé du serveur

Sur le serveur mail, à partir du fichier de certificat utilisé :

openssl x509 -in /etc/ssl/mail/fullchain.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

3. Publiez l'enregistrement TLSA

Host:  _25._tcp.mail      (for MX host mail.yourdomain.com)
Type:  TLSA
Usage: 3   Selector: 1   Matching type: 1
Value: <the SHA-256 hex hash>

Publiez un enregistrement par nom d'hôte MX. Le certificat doit rester un certificat valide classique dont le nom correspond à l'hôte, pour que les expéditeurs sans DANE et MTA-STS continuent de fonctionner.

4. Anticipez les renouvellements de certificat

C'est là que la plupart des configurations DANE cassent. Avec 3 1 1, l'empreinte suit la clé, pas le certificat, donc :

• Renouvelez les certificats en gardant la même clé privée (par exemple avec l'option --reuse-key de Certbot), ou
• Utilisez un schéma « actuelle + suivante » : générez la prochaine clé à l'avance, publiez un second enregistrement TLSA pour elle, attendez au moins deux TTL, puis basculez le serveur sur la nouvelle clé, et retirez l'ancien enregistrement plus tard.

5. Validez DANE à l'envoi (facultatif)

Si vous utilisez Postfix avec un résolveur local qui valide DNSSEC, activez DANE pour les emails sortants dans main.cf :

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Pour les bases du TLS sur votre propre serveur, voir les emails envoyés sans TLS.

Vérifiez que c'est corrigé

Attendez l'expiration des caches DNS, puis relancez dig +dnssec TLSA (la réponse doit revenir avec l'indicateur ad), comparez l'empreinte avec le certificat en service et relancez posttls-finger. Envoyez un email depuis une boîte extérieure vers votre domaine et vérifiez dans le journal du serveur mail que la connexion s'est faite en TLS. Lancez aussi un test Delivmail depuis votre serveur pour confirmer que l'envoi fonctionne toujours. Revérifiez après chaque renouvellement de certificat.