Safety
DANE TLSA vs CAA for Public Site Certificates
May 1, 2023
DANE TLSA vs CAA for public site certificates is two DNS controls that people mix up. CAA (RFC 8659) tells CAs which issuers may mint a cert for the name — a policy the CA ecosystem is supposed to honor. DANE (RFC 6698) puts a TLSA record in DNSSEC that says which leaf or CA key SMTP or TLS clients should accept. Major browsers do not use DANE for HTTPS. SMTP and some mail stacks do. A marketing site still wants CAA plus automated renewal and HSTS. RoastMyOpsec confirms HTTPS and the runtime trust store. It does not query CAA or TLSA, does not validate DNSSEC, and does not score missing DANE as an F.
The practical difference
CAA is issuance: who may create a cert. DANE is consumption: which key a DANE-aware client should trust, if DNSSEC is valid. Certificate Transparency is a public log of what was issued — see Expect-CT vs CT. Registrar lock stops someone else transferring the domain and rewriting CAA.
Publishing TLSA for HTTPS without a DANE-aware browser audience is busywork. Publishing CAA with issuewild and a CA you actually use is the usual first move.
How to choose a policy
Every public HTTPS name: CAA for your real CA (and issuewild if you use wildcards), DNSSEC optional but useful, registrar lock on. Skip HTTPS DANE unless you operate a stack that checks it. Mail: DANE/TLSA for MX is a different product than website CAA — pair with MTA-STS. Do not copy a TLSA that pins a leaf you rotate every 60 days unless automation updates DNS in the same pipeline.
| Control | Who honors it | Public website | Takeaway |
|---|---|---|---|
| CAA | CAs at issuance | Yes — name your CA | See CAA vs registrar lock |
| DANE TLSA | DANE-aware clients (often mail) | Browsers generally no | Optional; not a roast F |
| DNSSEC | Resolvers that validate | Helps CAA/DANE authenticity | See DNS hygiene |
| HSTS + renewal | Browsers | Yes | See expiry vs HSTS |
When DANE still wins
DANE wins for SMTP to an MX you operate with DNSSEC. CAA still wins for HTTPS issuance on the marketing host. Missing TLSA on a brochure is healthy. Pair with OCSP stapling if revocation ops are the worry, not DANE.
What the roast can prove
Trust-store acceptance of the leaf you were served. CAA and TLSA are out of scope. Confirm records in DNS. Pair with dangling CNAMEs if a leftover name still issues certs.
Common mistakes
The first mistake is TLSA on the website because 'DANE is stronger than CAA' while Chrome never looks.
The second mistake is CAA with no issuewild while you still order wildcard certs.
The third mistake is treating missing DANE as an HTTPS vulnerability.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does DANE replace CAA?
- No. CAA is for CAs at issuance. DANE is for clients that implement it — not typical browsers on HTTPS.
- Should brochure sites publish TLSA?
- Usually no for HTTPS. Publish CAA. Missing DANE is not a roast F.
- Does RoastMyOpsec check CAA or DANE?
- No. It does not query DNS TXT or TLSA and does not validate DNSSEC.