Aller au contenu principal
CaptainDNS
✦NOUVEAU·Surveillance sécurité et délivrabilité email. Soyez alerté dès qu'un changement de note ou d'enregistrement DNS menace votre domaine.En savoir plus

DANE TLSA Generator

Créez des enregistrements TLSA pour sécuriser vos connexions SMTP

Générez un enregistrement DANE TLSA à partir de votre certificat TLS. Sélectionnez le type d'usage, le sélecteur et le matching type, collez votre certificat PEM, et obtenez un enregistrement DNS prêt à publier.

1Serveur et certificat

Le nom du serveur MX (pas le domaine email). C'est l'hôte sur lequel l'enregistrement TLSA sera publié.

Source du certificat
Port 25 - DANE SMTP (RFC 7672). DANE pour SMTP est normalisé exclusivement sur le port 25 (MTA-to-MTA en STARTTLS). Le port est figé et ne se configure pas.
2Paramètres TLSA

Les valeurs par défaut (DANE-EE, SPKI, SHA-256) conviennent à la quasi-totalité des serveurs SMTP. Ne les modifiez que si vous savez ce que vous faites.

Usage (utilisation du certificat)
Selector
Matching Type

Support certificat PEM

Collez votre certificat au format PEM standard. L'outil extrait automatiquement les données nécessaires pour générer le hash TLSA.

Tous les paramètres TLSA

Pour le SMTP (RFC 7672), configurez les usages DANE-TA (2) et DANE-EE (3), 2 sélecteurs (Cert, SPKI) et 3 matching types (Full, SHA-256, SHA-512).

Prêt à copier-coller

Copie en un clic vers le presse-papiers. Inclut le nom DNS complet (_25._tcp.hostname) et la valeur de l'enregistrement TLSA.

Validation intégrée

Le certificat PEM est validé avant génération. Détection des formats invalides, certificats expirés et clés incompatibles.

Guide déploiement DNSSEC

Rappels et conseils pour activer DNSSEC avant de publier les enregistrements TLSA. DANE ne fonctionne pas sans DNSSEC.

Comment utiliser ce générateur DANE TLSA

Sans enregistrement TLSA valide, votre domaine ne bénéficie d'aucune protection DANE. Ce générateur crée un enregistrement prêt à publier en moins d'une minute.

Étape 1 : Configurer les paramètres TLSA

Sélectionnez les paramètres adaptés à votre infrastructure. Pour la majorité des cas, la configuration recommandée ci-dessous convient.

Configuration recommandée pour SMTP :

ParamètreValeur recommandéeRaison
Certificate UsageDANE-EE (3)Pas besoin de validation PKIX
SelectorSPKI (1)Survit aux renouvellements
Matching TypeSHA-256 (1)Compact et sécurisé
Port25Port SMTP standard

Étape 2 : Fournir le certificat

Collez votre certificat TLS au format PEM. Deux méthodes pour l'obtenir :

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQON...
-----END CERTIFICATE-----

Comment obtenir le certificat :

# Depuis votre serveur mail via STARTTLS
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>/dev/null | openssl x509

# Depuis un fichier sur le serveur
cat /etc/letsencrypt/live/mail.captaindns.com/cert.pem

Étape 3 : Copier et publier

Le générateur produit un enregistrement DNS complet, prêt à copier-coller dans votre zone DNS :

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4d

Étape 4 : Vérifier le déploiement

Après publication, lancez une vérification avec notre DANE TLSA Checker. Confirmez que l'enregistrement est résolu et que la chaîne DNSSEC est intacte.

Guide des paramètres TLSA

Certificate Usage : quel type choisir ?

Le champ usage détermine le niveau de contrainte appliqué au certificat. Ce choix impacte directement la maintenance DNS.

Pour le SMTP (RFC 7672), seuls DANE-TA (2) et DANE-EE (3) sont utilisés. PKIX-TA (0) et PKIX-EE (1) existent dans la RFC 6698 mais ne s'appliquent pas au SMTP opportuniste : les MTA s'appuient sur DNSSEC, pas sur la validation PKIX.

UsageNomQuand l'utiliserRotation de certificat
2DANE-TAÉpingler la CA (sans PKIX)Facile (même CA)
3DANE-EEÉpingler le certificat exact (sans PKIX)Moyen (SPKI + réutilisation clé)

Par défaut, choisissez DANE-EE (3) avec sélecteur SPKI (1) et matching SHA-256 (1). C'est le choix le plus simple et le plus robuste. DANE-TA (2) est une option avancée soumise à une contrainte de chaîne (voir les stratégies de déploiement).

Selector - Cert vs SPKI

SelectorStabilitéCas d'usage
Cert (0)Change à chaque renouvellementÉpinglage strict, gestion DNS automatisée
SPKI (1)Stable si même cléRecommandé, surtout avec Let's Encrypt

Utilisez SPKI (1) sauf si votre workflow impose un changement de clé à chaque renouvellement. SPKI réduit drastiquement la fréquence des mises à jour DNS.

Matching Type - Full vs Hash

MatchingTaille enregistrementSécurité
Full (0)Grande (peut tronquer UDP)Maximale
SHA-256 (1)64 caractères hexRecommandé
SHA-512 (2)128 caractères hexPlus long, sans bénéfice réel

SHA-256 (1) est le standard. Full (0) crée des enregistrements volumineux qui risquent la troncature UDP au-delà de 512 octets. SHA-512 n'offre aucun avantage pratique supplémentaire.

Prérequis : DNSSEC

DANE sans DNSSEC est inopérant. Les MTA ignorent tout enregistrement TLSA non signé. Activez DNSSEC avant de publier.

Vérifier DNSSEC

Suivez ces quatre étapes dans l'ordre :

  1. Confirmez que votre registrar supporte DNSSEC
  2. Activez la signature DNSSEC chez votre hébergeur DNS
  3. Ajoutez les enregistrements DS chez votre registrar
  4. Attendez la propagation DNS (24 à 48 heures selon les fournisseurs)

Fournisseurs DNS avec DNSSEC

FournisseurDNSSECNotes
CloudflareOui (automatique)Un clic dans les paramètres
AWS Route 53OuiConfiguration manuelle requise
OVHOuiActivation via manager
Google Cloud DNSOuiConfiguration manuelle
GandiOuiActivation automatique possible

Stratégies de déploiement

Scénario 1 : Let's Encrypt avec réutilisation de clé

Configuration :

# Générer avec réutilisation de clé
certbot certonly --reuse-key -d mail.captaindns.com

# TLSA record (ne changera pas entre renouvellements)
3 1 1 <sha256-spki>

Avantage : L'enregistrement TLSA ne change jamais tant que la clé est réutilisée.

Scénario 2 : Let's Encrypt avec DANE-TA (option avancée)

Avec DANE-TA (usage 2), le certificat épinglé - ou un certificat qu'il a signé - DOIT être présent dans la chaîne TLS envoyée par le serveur (RFC 7671 §5). Or les MTA n'envoient généralement PAS le certificat racine : épinglez l'intermédiaire effectivement servi (par exemple Let's Encrypt R10/R11), pas la racine ISRG Root X1.

Configuration :

# Épingler l'intermédiaire réellement envoyé par le serveur (ex. R10/R11)
2 1 1 <sha256-spki-de-l-intermediaire>

Avertissement : si vous épinglez une racine (ISRG Root X1), configurez le serveur pour qu'il inclue ce certificat dans la chaîne TLS, sinon la validation DANE-TA échoue. En cas de doute, préférez DANE-EE (3) + SPKI (1), qui n'a pas cette contrainte de chaîne.

Avantage : aucune mise à jour DNS nécessaire tant que l'intermédiaire reste inchangé dans la chaîne.

Scénario 3 : Rotation avec double enregistrement

Avant la rotation :

_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <hash-cert-actuel>
_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <hash-cert-futur>

Après la rotation : Supprimez l'ancien hash.

Publication DNS par fournisseur

Cloudflare

  1. Allez dans les paramètres DNS de votre domaine
  2. Ajoutez un enregistrement :
    • Type : TLSA
    • Nom : _25._tcp.mail
    • Usage : 3
    • Selector : 1
    • Matching Type : 1
    • Certificate : Votre hash SHA-256

AWS Route 53

  1. Ouvrez la zone hébergée
  2. Créez un enregistrement :
    • Nom : _25._tcp.mail.captaindns.com
    • Type : TLSA
    • Valeur : 3 1 1 <hash>
    • TTL : 3600

OVH / Format générique

  1. Allez dans la zone DNS
  2. Ajoutez une entrée :
    • Sous-domaine : _25._tcp.mail
    • Type : TLSA
    • Cible : 3 1 1 <hash>
    • TTL : 3600

Bonnes pratiques et pièges courants

DANE est strict : une erreur de configuration bloque la réception du courrier. Évitez ces pièges classiques.

  • DNSSEC obligatoire : sans une zone signée et validée, les résolveurs ignorent l'enregistrement TLSA et DANE devient totalement inopérant. C'est l'erreur numéro un.
  • Rotation additive : publiez le NOUVEL enregistrement TLSA EN PLUS de l'ancien, attendez la propagation DNS et l'expiration du TTL, puis ne retirez l'ancien qu'après la mise hors service de l'ancien certificat. Ne supprimez jamais l'ancien avant la propagation du nouveau.
  • Publish-then-deploy : publiez et laissez propager l'enregistrement TLSA AVANT de basculer le certificat sur le serveur, jamais l'inverse.
  • SPKI survit au renouvellement : avec le sélecteur SPKI (1), tant que la même clé est réutilisée, l'enregistrement reste valide après renouvellement, ce qui réduit les mises à jour DNS. Le sélecteur Cert (0) oblige à republier à chaque renouvellement.
  • Correspondance avec le certificat servi : l'enregistrement TLSA doit correspondre au certificat réellement présenté par le MX. Un décalage hostname/certificat provoque l'échec de la validation.

Sécurité email complète avec DANE

DANE seul ne suffit pas. Une stratégie de sécurité du transport email complète combine trois mécanismes complémentaires.

1. DANE (Authentification certificat via DNS)

Vérifie l'identité du serveur destinataire via DNSSEC.

2. MTA-STS (Application TLS via HTTPS)

Alternative à DANE sans DNSSEC.

3. TLS-RPT (Rapporter les échecs)

Rapporte les échecs de connexion TLS (DANE et MTA-STS).

Ordre de déploiement recommandé

Respectez cette séquence pour éviter les faux positifs dans les rapports :

  1. Activez DNSSEC sur le domaine
  2. Publiez les enregistrements TLSA (DANE) - utilisez ce générateur
  3. Configurez TLS-RPT pour recevoir les rapports d'échec
  4. Ajoutez MTA-STS comme couche de protection supplémentaire
  5. Surveillez les rapports TLS-RPT après chaque renouvellement de certificat

FAQ - Questions fréquentes

Q : Comment créer un enregistrement DANE TLSA ?

R : Utilisez notre générateur : sélectionnez le type d'usage (DANE-EE recommandé), le sélecteur (SPKI pour la stabilité), le matching type (SHA-256), et collez votre certificat PEM. L'outil génère l'enregistrement DNS complet prêt à publier.

Q : Quel usage de certificat choisir pour DANE ?

R : Pour la plupart des déploiements SMTP, DANE-EE (3) avec sélecteur SPKI et matching SHA-256 est recommandé. Pour faciliter la rotation de certificat, utilisez DANE-TA (2) avec le certificat de votre CA.

Q : Faut-il utiliser le certificat complet ou un hash ?

R : Utilisez toujours un hash SHA-256. Les données complètes (matching type 0) créent des enregistrements DNS très grands avec des risques de troncature UDP. SHA-256 produit une chaîne compacte de 64 caractères.

Q : Qu'est-ce que le sélecteur SPKI ?

R : Le sélecteur SPKI (1) ne hash que la clé publique du certificat. L'enregistrement TLSA reste valide quand vous renouvelez avec la même paire de clés, contrairement au sélecteur Cert (0) qui change à chaque renouvellement.

Q : Comment déployer un enregistrement DANE TLSA ?

R : 1) Activez DNSSEC, 2) Ajoutez le TLSA à _25._tcp.votreserveurmail, 3) Attendez la propagation DNS, 4) Vérifiez avec notre DANE TLSA Checker. L'enregistrement doit être signé DNSSEC.

Q : Comment gérer les renouvellements Let's Encrypt avec DANE ?

R : Deux stratégies : DANE-TA (usage 2) avec le certificat CA Let's Encrypt survit automatiquement aux renouvellements. DANE-EE (usage 3) avec sélecteur SPKI et --reuse-key dans Certbot fonctionne aussi.

Outils complémentaires

OutilUtilité
DANE TLSA ValidatorValider la syntaxe avant publication
DANE TLSA CheckerVérifier l'enregistrement après déploiement
Générateur MTA-STSCréer une politique MTA-STS (sécurité TLS alternative)
Générateur TLS-RPTActiver le reporting des échecs DANE
Hébergement MTA-STSAjoutez MTA-STS en complément avec des politiques hébergées gratuitement
Audit domaine emailAudit complet de l'authentification email

Ressources utiles