Expert Tools

DANE (DNS-based Authentication of Named Entities) publishes a fingerprint of the certificate a website or mail server is supposed to use, as a TLSA record in DNS. A connecting client that checks DANE can then refuse to trust a certificate - even one issued by a normally-trusted CA - if it doesn't match what's published, closing off attacks where a certificate is issued by a different, compromised, or coerced certificate authority.

DNSSEC is not optional here

A TLSA record is only as trustworthy as the DNS response carrying it. Without DNSSEC, nothing stops that record from being tampered with in transit, which defeats the entire point - so this check verifies DNSSEC first, and every other finding below should be read in that light.

What "usage 2 1 1" actually means

A TLSA record has four numbers: usage, selector, matching type, then the hash itself. Usage 2 (DANE-TA) pins the certificate authority - usually an intermediate - rather than the certificate itself, which is why it survives routine renewal instead of needing an update every time a short-lived certificate rotates. Selector 1 means the hash covers just the public key, not the whole certificate. Matching type 1 means SHA-256. This check shows what it found in plain language, not just the raw numbers.

Mail is checked differently to the website

Port 443 is encrypted from the first byte, so the certificate is available immediately. Port 25 (SMTP) starts in plaintext and only upgrades to TLS mid-conversation via STARTTLS - a fundamentally different handshake, implemented separately here for that reason. Every MX host gets its TLSA record checked; only the primary (lowest-preference) one gets verified against its actual, live certificate, to keep this check from turning into a full STARTTLS handshake per mail server on every run.

A note on the Wizard tab

The Wizard builds a record from whatever certificate is being served right now. If the served intermediate matches a known CA in our own sourced list (lib/data/ca-intermediates.json - independently verified against each CA's own repository, not guessed), it offers pinning that CA's entire current rotation in one click - every active and backup intermediate that CA currently publishes, not just today's single certificate. That's the difference between a record that survives a routine CA-side rotation and one that needs a DNS change every time the CA switches which intermediate it's signing with. An unrecognised certificate still gets the single-certificate option, same as before - it just won't get the one-click multi-record shortcut.