A Registro TLSA associa un servizio TLS al certificato o ai dati della chiave pubblica. Non è un registrazione TXT, un sostituto per un Record MX o prove che ogni mittente utilizza DANE. Per SMTP , il comportamento di rilevamento e applicazione rilevante è definito dalla RFC 7672 .
Inizia con il nome host del servizio MX
Riferimenti: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
Per un servizio sulla porta TCP 25 a mx.example.com, è il proprietario convenzionale del TLSA _25._tcp.mx.example.com. Derivare il nome dal nome host effettivo dello scambio SMTP , non automaticamente dal dominio Da visibile o dall'apice della zona. Controlla ogni endpoint MX che la distribuzione intende proteggere e il file DNSSEC stato lungo il percorso di scoperta.
I campi dati TLSA riguardano l'utilizzo del certificato, selettore, corrispondente al tipo e ai dati di associazione. Per questo semplice percorso senza alias, il proprietario mostrato è sufficiente; gli alias richiedono la gestione del dominio base TLSA autenticato nella RFC 7672 §2.2. Un profilo DANE SMTP comunemente consigliato è 3 1 1: utilizzo DANE-EE, selezione ObjectPublicKeyInfo e corrispondenza SHA-256. Questi numeri rappresentano scelte di protocollo significative, non un prefisso generico per il testo arbitrario del certificato. RFC 7672 e RFC 7671 descrivono gli usi supportati e le considerazioni operative; mantenere le combinazioni non supportate fuori da una ricetta di distribuzione.
Deriva i byte esatti
Riferimenti: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
Per un file di certificato PEM locale cert.pem, in una shell Bash abilitare prima set -o pipefail; viene quindi creata una pipeline digest SPKI riproducibile openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Richiedi che ogni fase abbia successo. Hashing la rappresentazione della chiave pubblica DER, non il testo PEM, l'impronta digitale visualizzata o l'intero certificato quando è previsto il selettore 1.
Costruire _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, sostituendo HEXDIGEST con il digest effettivo. Questo è un modello, non un record pubblicabile. Ottenere il certificato presentato dall'endpoint SMTP previsto tramite un file controllato STARTTLS ispezione e confrontare i byte selezionati. Un file locale può differire dal certificato effettivamente servito dal server.
Testare un cambiamento chiave prima di ritirare la vecchia associazione
Riferimenti: RFC 7672 §4, RFC 7671 §8.
L'apparecchiatura sintetica A utilizza un certificato di test con la chiave A e un'associazione TLSA derivata da A. Il confronto dei byte previsto corrisponde a una corrispondenza. L'apparecchio B fornisce un certificato con la chiave B mantenendo solo l'associazione di A; il confronto previsto è una mancata corrispondenza. L'apparecchio C pubblica entrambe le associazioni accettabili per una transizione pianificata e verifica l'endpoint previsto rispetto a B prima di ritirare A.
La tempistica deve tenere conto dei dati TLSA memorizzati nella cache e di tutte le istanze del server attive. Un certificato rinnovato con la stessa chiave pubblica può mantenere la stessa 3 1 1 associazione, mentre una nuova chiave la cambia. Un confronto digest riuscito è un controllo crittografico locale, non un risultato di interoperabilità SMTP DANE . I test DNSSEC e SMTP in tempo reale rimangono requisiti di prova separati.
Verifica il trasporto anziché l'etichetta del dashboard
Riferimenti: RFC 7672 §2.2, RFC 7672 §3.
Utilizza un percorso di convalida DNSSEC per stabilire dati TLSA utilizzabili, quindi testa l'effettivo handshake SMTP e l'associazione con un'implementazione compatibile con DANE. Conserva le risposte DNS , la traccia di convalida, la catena di certificati, l'associazione selezionata e il risultato del mittente. Un mittente di supporto non dovrebbe considerare silenziosamente un'autenticazione DANE richiesta non riuscita come una consegna sicura riuscita. Non rivendicare la protezione universale del trasporto: il supporto del mittente e l'esatto risultato del rilevamento autenticato contano.
Associazioni osservate e controlli di rilevamento
Riferimenti: RFC 4035 §5.
L'evento firmato il 7 novembre 2026 conservato, ispezionato ma non rieseguito per questa revisione, convalida un TLSA RRset tramite un genitore bloccato, DS autenticato e DNSKEY figlio. Un servizio TLS di loopback separato ha effettivamente presentato il certificato di test A e poi B. L'estrazione di SPKI da ciascun certificato di handshake ricevuto ha prodotto una corrispondenza per A contro A, una mancata corrispondenza per B contro A solo, una corrispondenza per B durante una sovrapposizione A/B e una corrispondenza per B dopo il ritiro di A. La trascrizione registra timestamp, endpoint di loopback, protocollo TLS e digest. Ciò convalida gli ingredienti crittografici separati; il servizio era TLS ordinario, non SMTP STARTTLS e non viene richiesto alcun client di posta DANE integrato o test del risolutore DNS live.