Skip to content

tls.cert.dane_ee_pinned

Certificate Pinned by DANE-EE

What we check

After the STARTTLS handshake we look up the host's TLSA records at _25._tcp.<mx-hostname> through a validating resolver and match the presented certificate against every DNSSEC-validated DANE-EE (usage 3) record. This finding appears when the chain does not validate against a trusted CA — self-signed or otherwise untrusted — but a DANE-EE record pins the certificate.

What this finding means

The server relies on DANE rather than a certificate authority to prove its identity. A DANE-EE record publishes the certificate (or its public key) in DNS, signed with DNSSEC; a DANE-aware sender verifies the key against that record and does not need a CA at all (RFC 7672 §3.1). The certificate is therefore not a broken chain, and it is not graded as one.

Why it matters

How to fix

Nothing is required for DANE. If you also want senders without DANE to validate the connection, deploy a CA-issued certificate (for example from Let's Encrypt) and keep the TLSA record in sync with it — a 3 1 1 record over the public key survives certificate renewals as long as the key stays the same.

How it's graded

Informational, no deduction. The instant F for an untrusted chain does not apply while a validated DANE-EE record matches the certificate; the DANE checks themselves are graded separately. Expiry is not covered by the pin: an expired certificate keeps its own instant F, because most senders still validate the classic way. See Grading Methodology.

Evidence example

$ dig +dnssec TLSA _25._tcp.mail.example.com +short
3 1 1 2ABDD2F9…   ← usage 3 (DANE-EE), selector 1 (SPKI), SHA-256
$ openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null \
    | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
2abdd2f9…            ← matches the TLSA record

References