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
- Correct by design. RFC 7672 explicitly allows — and DANE deployments commonly use — self-signed certificates pinned by DANE-EE records. Grading them as invalid chains would punish a stronger authentication model.
- Only for DANE senders. Senders that do not implement DANE still validate the chain the classic way and see an untrusted certificate. Whether that matters depends on who sends you mail.
- DNSSEC is the anchor. The pin is only as good as the DNSSEC chain that signs it; an unsigned TLSA record proves nothing and is not treated as a pin.
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