A Enregistrement TLSA associe un service TLS à des données de certificat ou de clé publique. Ce n'est pas un Enregistrement TXT, en remplacement d'un Enregistrement MX ou une preuve que chaque expéditeur utilise DANE. Pour SMTP , le comportement de découverte et d'application pertinent est défini par RFC 7672 .
Commencez par le nom d'hôte du service MX
Références : RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
Pour un service sur le port TCP 25 à mx.example.com, le propriétaire TLSA conventionnel est _25._tcp.mx.example.com. Dérivez le nom du nom d'hôte réel de l'échange SMTP , et non automatiquement du nom visible du domaine ou de la zone. Vérifiez chaque point de terminaison MX que le déploiement vise à protéger et le DNSSEC statut le long du chemin de découverte.
Les champs de données TLSA concernent l'utilisation du certificat, sélecteur, correspondant au type et aux données d'association. Pour cet itinéraire simple sans alias, le propriétaire indiqué est suffisant ; les alias nécessitent la gestion du domaine de base TLSA authentifié dans RFC 7672 §2.2. Un profil SMTP DANE couramment recommandé est 3 1 1: utilisation de DANE-EE, sélection de SubjectPublicKeyInfo et correspondance SHA-256. Ces numéros sont des choix de protocole significatifs et non un préfixe générique pour un texte de certificat arbitraire. RFC 7672 et RFC 7671 décrivent les utilisations prises en charge et les considérations opérationnelles ; gardez les combinaisons non prises en charge hors d’une recette de déploiement.
Dériver les octets exacts
Références : RFC 6698 §2.1.2, RFC 6698 §2.1.3.
Pour un fichier de certificat PEM local cert.pem, dans un shell Bash, activez d'abord set -o échec de pipe; un pipeline de digestion SPKI reproductible est alors openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst-sha256. Exigez que chaque étape réussisse. Hachez la représentation de la clé publique DER, et non le texte PEM, l'empreinte digitale affichée ou l'intégralité du certificat lorsque le sélecteur 1 est prévu.
Construction _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, en remplaçant HEXDIGEST par le résumé réel. Il s'agit d'un modèle et non d'un enregistrement publiable. Obtenez le certificat présenté par le point de terminaison SMTP prévu via une procédure contrôlée. STARTTLS inspection et comparer ses octets sélectionnés. Un fichier local peut différer du certificat que le serveur sert réellement.
Tester un changement clé avant de retirer l’ancienne association
Références : RFC 7672 §4, RFC 7671 §8.
L'appareil synthétique A utilise un certificat de test avec la clé A et une association TLSA dérivée de A. La comparaison d'octets attendue est une correspondance. Le luminaire B sert un certificat avec la clé B tout en conservant uniquement l'association de A ; la comparaison attendue est une inadéquation. Le luminaire C publie les deux associations acceptables pour une transition planifiée et vérifie le point final prévu par rapport à B avant de retirer A.
Le timing doit tenir compte des données TLSA mises en cache et de toutes les instances de serveur actives. Un certificat renouvelé avec la même clé publique peut conserver la même 3 1 1 association, alors qu'une nouvelle clé la change. Une comparaison de résumé réussie est une vérification cryptographique locale, et non un résultat d'interopérabilité SMTP DANE . Les tests DNSSEC et SMTP en direct restent des exigences de preuve distinctes.
Vérifier le transport plutôt qu'une étiquette de tableau de bord
Références : RFC 7672 §2.2, RFC 7672 §3.
Utilisez un chemin de validation DNSSEC pour établir des données TLSA utilisables, puis testez la prise de contact SMTP réelle et l'association avec une implémentation compatible DANE. Préservez les réponses DNS , la trace de validation, la chaîne de certificats, l'association sélectionnée et le résultat de l'expéditeur. Un expéditeur prenant en charge ne doit pas traiter silencieusement un échec de l'authentification DANE requise comme une livraison sécurisée réussie. Ne revendiquez pas la protection universelle du transport : la prise en charge de l’expéditeur et le résultat exact de la découverte authentifié sont importants.
Association observée et contrôles de découverte
Références : RFC 4035 §5.
L'appareil signé retenu le 7 novembre 2026, inspecté mais non réexécuté pour cet examen, valide un RRset TLSA via un parent épinglé, un DS authentifié et une DNSKEY enfant. Un service TLS de bouclage distinct présentait en fait le certificat de test A, puis B. L'extraction du SPKI de chaque certificat de prise de contact reçu a produit une correspondance pour A contre A, une discordance pour B contre A seul, une correspondance pour B lors d'un chevauchement A/B et une correspondance pour B après le retrait de A. La transcription enregistre les horodatages, les points de terminaison de bouclage, le protocole TLS et les résumés. Cela valide les ingrédients cryptographiques distincts ; le service était TLS ordinaire, pas SMTP STARTTLS , et aucun client de messagerie DANE intégré ou test de résolution DNS en direct n'est revendiqué.