A Rekord TLSA kojarzy usługę TLS z danymi certyfikatu lub klucza publicznego. To nie jest Rekord TXT, zamiennik dla Rekord MX lub dowód, z którego korzysta każdy nadawca DANE. W przypadku SMTP odpowiednie zachowanie związane z wykrywaniem i egzekwowaniem jest zdefiniowane w RFC 7672 .
Zacznij od nazwy hosta usługi MX
Referencje: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
Dla usługi na porcie TCP 25 o godz mx.example.com, jest konwencjonalnym właścicielem TLSA _25._tcp.mx.example.com. Wyprowadź nazwę na podstawie rzeczywistej nazwy hosta wymiany SMTP , a nie automatycznie na podstawie widocznego wierzchołka domeny lub strefy Z. Sprawdź każdy punkt końcowy MX , który wdrożenie ma chronić, oraz DNSSEC statusu na ścieżce odkrywania.
Pola danych TLSA dotyczą użycia certyfikatu, selektor, pasujący typ i dane powiązania. W przypadku tej prostej, niealiasowanej trasy wystarczy pokazany właściciel; aliasy wymagają uwierzytelnionej obsługi domeny bazowej TLSA zgodnie z RFC 7672 §2.2. Powszechnie zalecanym profilem SMTP DANE jest 3 1 1: użycie DANE-EE, wybór topicPublicKeyInfo i dopasowanie SHA-256. Liczby te oznaczają znaczące wybory protokołu, a nie ogólny przedrostek dowolnego tekstu certyfikatu. RFC 7672 i RFC 7671 opisują obsługiwane zastosowania i względy operacyjne; nieobsługiwane kombinacje należy trzymać poza przepisem wdrożenia.
Uzyskaj dokładne bajty
Referencje: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
Dla lokalnego pliku certyfikatu PEM certyfikat.pem, w powłoce Bash najpierw włącz set -o awaria potoku; wówczas powstaje powtarzalny potok trawienia SPKI openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Wymagaj, aby każdy etap zakończył się sukcesem. Zaszyfruj reprezentację klucza publicznego DER, a nie tekst PEM, wyświetlany odcisk palca lub cały certyfikat, jeśli przeznaczony jest selektor 1.
Skonstruować _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, zastępując HEXDIGEST rzeczywistym skrótem. To jest szablon, a nie zapis nadający się do publikacji. Uzyskaj certyfikat prezentowany przez zamierzony punkt końcowy SMTP za pośrednictwem kontrolowanego STARTTLS sprawdź i porównaj wybrane bajty. Plik lokalny może różnić się od certyfikatu faktycznie obsługiwanego przez serwer.
Przetestuj kluczową zmianę przed wycofaniem starego powiązania
Referencje: RFC 7672 §4, RFC 7671 §8.
Urządzenie syntetyczne A używa certyfikatu testowego z kluczem A i powiązaniem TLSA wyprowadzonym z A. Oczekiwane porównanie bajtów jest zgodne. Urządzenie B udostępnia certyfikat z kluczem B, zachowując tylko powiązanie z A; oczekiwane porównanie jest niedopasowaniem. Urządzenie C publikuje oba akceptowalne powiązania dla planowanego przejścia i weryfikuje zamierzony punkt końcowy względem B przed wycofaniem A.
Czas musi uwzględniać buforowane dane TLSA i wszystkie aktywne instancje serwerów. Certyfikat odnowiony przy użyciu tego samego klucza publicznego może pozostać taki sam 3 1 1 skojarzenie, natomiast nowy klucz je zmienia. Pomyślne porównanie skrótu to lokalna kontrola kryptograficzna, a nie wynik interoperacyjności SMTP DANE . Testy DNSSEC i SMTP na żywo pozostają odrębnymi wymogami dowodowymi.
Sprawdź transport, a nie etykietę na desce rozdzielczej
Referencje: RFC 7672 §2.2, RFC 7672 §3.
Użyj ścieżki sprawdzającej DNSSEC, aby ustalić użyteczne dane TLSA, a następnie przetestuj rzeczywiste uzgadnianie SMTP i powiązanie z implementacją obsługującą DANE. Zachowaj odpowiedzi DNS , ślad weryfikacyjny, łańcuch certyfikatów, wybrane powiązanie i wynik nadawcy. Nadawca pomocniczy nie powinien po cichu traktować nieudanego wymaganego uwierzytelnienia DANE jako pomyślnej, bezpiecznej dostawy. Nie żądaj uniwersalnej ochrony transportu: liczy się wsparcie nadawcy i dokładny wynik uwierzytelnionego odkrycia.
Obserwowane kontrole powiązań i odkrywania
Referencje: RFC 4035 §5.
Zachowane urządzenie podpisane 7 listopada 2026 r., sprawdzone, ale nie uruchomione ponownie na potrzeby tego przeglądu, sprawdza zestaw RR TLSA poprzez przypięty nadrzędny, uwierzytelniony DS i podrzędny klucz DNSKEY. Oddzielna usługa TLS z pętlą zwrotną faktycznie przedstawiła certyfikat testowy A, a następnie B. Wyodrębnienie SPKI z każdego otrzymanego certyfikatu uzgadniania spowodowało dopasowanie A do A, niedopasowanie B do samego A, dopasowanie B podczas nakładania się A/B i dopasowanie dla B po wycofaniu się A. Transkrypt rejestruje znaczniki czasu, punkty końcowe pętli zwrotnej, protokół TLS i skróty. To sprawdza oddzielne składniki kryptograficzne; usługa była zwykłą TLS , a nie SMTP STARTTLS i nie wymagano zintegrowanego klienta poczty DANE ani testu rozpoznawania DNS na żywo.