DANE & TLSA Certificate Pinning Inspector
Inspect RFC 6698 TLSA records, decode cryptographic parameters, verify DNSSEC trust chain anchoring, and generate hardened DANE certificate pinning policies.
🛠️ RFC 6698 TLSA Record Generator
Frequently Asked Questions
What is DANE and why is it superior to traditional CA certificate validation?
DNS-based Authentication of Named Entities (DANE, RFC 6698) binds X.509 certificates directly to DNS names using cryptographically signed DNSSEC. Traditional WebPKI trusts hundreds of commercial Certificate Authorities; if any single CA is compromised or coerced, attackers can issue rogue certificates. DANE eliminates this vulnerability by making the domain zone itself the authoritative root of trust.
What are the 4 Certificate Usage types defined in RFC 6698 TLSA records?
Usage 0 (PKIX-TA) pins a CA root that must also validate via public PKI. Usage 1 (PKIX-EE) pins an end-entity certificate that must pass public PKI. Usage 2 (DANE-TA) establishes a custom trust anchor bypassing commercial CAs entirely. Usage 3 (DANE-EE) binds a domain certificate or public key directly without requiring any commercial CA signatures.
Why is DNSSEC mandatory for DANE / TLSA to be secure?
Without DNSSEC cryptographic validation, an adversary performing DNS cache poisoning could forge spoofed TLSA records and substitute their own public key. Mail transfer agents and clients verifying DANE strictly mandate an authenticated DNSSEC chain of trust from the root zone down to the leaf TLSA record.
How are TLSA record names structured for mail and web ports?
TLSA records use prefixed labels specifying the port number and transport protocol: _<port>._<proto>.<hostname>. For example, SMTP port 25 on mail.example.com resides at _25._tcp.mail.example.com, and HTTPS port 443 resides at _443._tcp.example.com.