<b>What actually stops any Certificate Authority from issuing a certificate for your domain?</b>

<b>What actually stops any Certificate Authority from issuing a certificate for your domain?</b>

The primary technical control is the CAA DNS record (RFC 8659), and its enforcement model is precise in a way operators often miss.

Without CAA, the WebPKI's default is permissive: every publicly-trusted CA may issue for any domain. CAA (Certification Authority Authorization) inverts that default for your zone. A record like example.com. CAA 0 issue "letsencrypt.org" declares that only Let's Encrypt may issue certificates for that name.

The enforcement point is the crux. CAA is checked at issuance time by the CA, not at validation time by the browser. A conforming CA is mandated by the CA/Browser Forum Baseline Requirements to query CAA and refuse issuance if a record forbids it. Browsers do not check CAA — so a CA that ignores the record (or a compromised one) can still issue, and the client won't notice. CAA constrains honest CAs; it is a policy fence, not a cryptographic wall.

The tag set is worth knowing: issue (standard certs), issuewild (wildcards specifically), and iodef (a URL where the CA reports rejected issuance attempts — a free misissuance alarm). CAA also climbs the DNS tree, so a record at the parent applies unless a subdomain overrides it.

Further reading: RFC 8659, RFC 8657 (CAA for ACME account binding); CA/Browser Forum Baseline Requirements §3.2.2.8.

Bottom line: CAA tells honest CAs who may issue, enforced at issuance not validation — set iodef to get alerted whenever someone tries to obtain a cert you didn't authorize.