> How CAs check domain control with ACME HTTP-01, DNS-01 and TLS-ALPN-01, what DV, OV and EV mean, what the padlock proves, and how CAA works. Source: https://pkizerotohero.com/handbook/domain-validation/ · Last reviewed: 2026-10-20 Part III: Certificates · Chapter 11 # Proving you own the name: DV, OV, EV and CAA **In one sentence:** Before issuing, a CA checks that you control each name, using a file, a DNS record or a TLS response, and reads CAA records; OV and EV check the organisation. ## Who is this for - [IT ops](https://pkizerotohero.com/start/#itops) - [Developer](https://pkizerotohero.com/start/#developer) - [Leader](https://pkizerotohero.com/start/#leader) - [Expert](https://pkizerotohero.com/start/#expert) - [Beginner](https://pkizerotohero.com/start/#beginner) Level: **Practitioner** - [New to this? Start with The idea](https://pkizerotohero.com/handbook/domain-validation/#the-idea) - [Developer? Jump to How it really works](https://pkizerotohero.com/handbook/domain-validation/#how-it-really-works) - [IT ops? At work](https://pkizerotohero.com/handbook/domain-validation/#at-work) - [Leader? Why it matters](https://pkizerotohero.com/handbook/domain-validation/#why-it-matters-to-the-business) ## The idea - Beginner Anyone can send a CA a request for any name. In [chapter 10](https://pkizerotohero.com/handbook/csr/) you saw that the CSR’s signature proves only that the sender holds a private key. So before a CA signs a certificate for `shop.example.com`, it must check that the requester really controls `shop.example.com`. This check is called [domain validation](https://pkizerotohero.com/handbook/glossary/#domain-validation). For a website, “controlling the name” means one of these: - you can put a file on the website at that name; - you can add a record to the name’s DNS; - you can answer a special TLS connection at that name. The CA gives you a random challenge, you place it where only the name’s controller could, and the CA checks it from the outside. Certificates come in three validation levels: - **DV, domain validated**: the CA checked control of the names and nothing else. Most website certificates today are DV. - **OV, organisation validated**: the CA also checked that the organisation named in the certificate exists. - **EV, extended validation**: the CA ran stricter checks on the organisation, following a separate rulebook. All three give exactly the same encryption. The difference is only in what the CA checked about **who** asked. That is why the padlock, or whatever icon your browser now shows, means less than people think. It means your connection is encrypted and really goes to the name in the address bar. It does not mean the site is honest. A phishing site at `examp1e-login.com` can get a DV certificate for its own name in minutes, because it really does control that name. Domain owners have one more tool: a [CAA record](https://pkizerotohero.com/handbook/glossary/#caa-record) in DNS. It lists which CAs may issue certificates for the name. Every public CA must check it before issuing. In the game In the game: the Surveyors' Office In Level 11, Mallory asks Lord Notarius for a certificate in Rosa’s name. The surveyors ask her to plant a marker on Rosa’s land, and she cannot, so the request fails. Ken then checks the kingdom’s CAA notice that says which notaries may issue for the castle. Where the analogy stops being true: a surveyor checks who owns the land. A CA checks only who **controls** the website or DNS at that moment. If an attacker takes over your DNS account, they pass the check, so protecting those accounts is part of protecting your certificates. ## How it really works - Developer - Expert ### What do DV, OV and EV actually check? The [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/) (BRs) of the CA/Browser Forum set the rules for DV, OV and the less common IV (individual validated). The [EV Guidelines](https://cabforum.org/working-groups/server/extended-validation/guidelines/) add the EV rules: the applicant’s legal existence, physical address and operational activity, and the authority of the people who request the certificate. Each type has a policy identifier that the CA puts in the certificate: | Type | What the CA verified | Policy OID | What the subject shows | | --- | --- | --- | --- | | DV | Control of every name | `2.23.140.1.2.1` | Usually only a CN, or nothing | | OV | Control, plus the organisation | `2.23.140.1.2.2` | Organisation, locality, country | | IV | Control, plus an individual person | `2.23.140.1.2.3` | The person’s name | | EV | Control, plus stricter organisation checks | `2.23.140.1.1` | Also jurisdiction, business category and registration number | Every type needs domain validation first. OV and EV are additions, not replacements. ### How does a CA check domain control? BR section 3.2.2.4 lists the allowed methods, such as an email to a fixed address at the domain, a DNS change, or a change to the website. Automated CAs use the methods of the ACME protocol, RFC 8555. In each ACME challenge, the CA sends a random token. Your client combines it with a fingerprint of your ACME account key to form the **key authorization** ([RFC 8555 section 8.1](https://www.rfc-editor.org/rfc/rfc8555#section-8.1)). That binding means only your account can use a passed challenge. - **HTTP-01** ([section 8.3](https://www.rfc-editor.org/rfc/rfc8555#section-8.3)): you serve the key authorization at `http:///.well-known/acme-challenge/`. The CA fetches it over plain HTTP on port 80. - **DNS-01** ([section 8.4](https://www.rfc-editor.org/rfc/rfc8555#section-8.4)): you publish a TXT record at `_acme-challenge.`, holding the base64url SHA-256 hash of the key authorization. - **TLS-ALPN-01** ([RFC 8737](https://www.rfc-editor.org/rfc/rfc8737)): on port 443, your server answers a TLS connection that asks for the special protocol `acme-tls/1` with a temporary certificate that carries the key authorization hash. *Diagram: Three rows, one per ACME challenge. HTTP-01: the CA fetches a file under slash well-known slash acme-challenge over port 80; wildcard certificates not allowed, marked with a cross. DNS-01: the CA looks up a TXT record at underscore acme-challenge; wildcard certificates allowed, marked with a tick. TLS-ALPN-01: the CA opens a TLS connection on port 443 asking for acme-tls slash 1 and checks a special certificate; wildcard certificates not allowed, marked with a cross.* Three ways to prove control of a name. Only the DNS challenge can validate a wildcard. ### Why do wildcards need DNS-01? A wildcard such as `*.example.com` covers names that may not exist yet, so proving control of one website is not enough. The BRs mark which methods may validate a wildcard: the website change methods and the TLS-ALPN method may not (“If A is a Wildcard Domain Name, the CA MUST choose a validation method with a check in the Wildcard column”, section 3.2.2.4). In ACME terms, a wildcard needs a DNS-based challenge, in practice DNS-01. [Let’s Encrypt’s documentation](https://letsencrypt.org/docs/challenge-types/) says the same for HTTP-01: “This challenge cannot be used to issue wildcard certificates.” ### Why do CAs check from several places? An attacker who can briefly redirect internet traffic for your addresses, for example by announcing a false route near the CA, could answer a challenge in your place. The defence is to check from several networks at once and require them to agree. The BRs now require this: CAs must repeat domain validation and CAA checks from several network locations (phased in from 15 March 2025). The industry calls it [multi-perspective issuance corroboration](https://pkizerotohero.com/handbook/glossary/#multi-perspective-issuance-corroboration) (MPIC). ### How long does a validation stay valid? A CA may reuse a successful domain validation for a limited time before it must check again. Today that is 200 days. From 15 March 2029, it falls to 10 days, so in practice every renewal will need a fresh check. This is one reason to automate ([chapter 20](https://pkizerotohero.com/handbook/acme/)). ### What is CAA and how is it checked? Certification Authority Authorization is defined in RFC 8659. Before issuing, a public CA must look up CAA records for every name in the certificate and follow them (BR section 4.2.2.1). The main properties are: - **`issue`**: which CA may issue certificates for the name. `issue ";"` with no CA forbids all issuance. - **`issuewild`**: the same for wildcard certificates. It “takes precedence over each issue Property” for wildcards. - **`iodef`**: where a CA may report a refused request, for example a `mailto:` address. The CA finds the relevant records by climbing the DNS tree ([section 3](https://www.rfc-editor.org/rfc/rfc8659#section-3)): for `www.shop.example.com` it looks there first, then at `shop.example.com`, then at `example.com`, and stops at the first name that has CAA records. If it finds none, or only records that restrict nothing (such as `iodef` alone), CAA does not restrict issuance. A flag value of 128 marks a property as critical: a CA that does not understand a critical property must not issue. Two limits matter. CAA is checked only by CAs, at issuance: “Relying Parties MUST NOT use CAA records as part of certificate validation” ([section 1](https://www.rfc-editor.org/rfc/rfc8659#section-1)). And it binds honest CAs, so it cannot stop a CA that ignores the rules. [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657) adds two optional parameters, `accounturi` and `validationmethods`, which limit issuance to one ACME account or to certain challenge types at CAs that support them. ### What does the padlock mean today? The browser’s icon tells you that the connection is encrypted, that the certificate is valid for the name in the address bar, and that it chains to a trusted root. It says nothing about the site’s intentions. Browsers have moved away from suggesting otherwise: Chrome replaced the padlock in the address bar with a neutral settings icon (Chrome 117, September 2023), and Chrome and Firefox moved the EV company name out of the address bar (2019, in Chrome 77 and Firefox 70). The organisation details of OV and EV certificates are still in the certificate, one click away. ### How do attackers try to fool a CA, and how do you defend? Attackers rarely break the cryptography. They go after the validation channel or the people behind it: - **Taking over a DNS or registrar account**, then passing DNS-01 for real. Defend with multi-factor authentication, a registrar lock and few people with access. - **Getting a mailbox that a CA trusts**, such as `admin@` or `webmaster@` at your domain, which the BRs allow for email validation. Do not let those addresses be created by anyone outside the team that runs the domain. - **Redirecting traffic** to answer an HTTP-01 challenge. MPIC makes this much harder. - **Fooling OV and EV checks** with real but confusing company registrations, such as a new company with a famous name in another state or country. This is why the organisation name alone is weak evidence. - **Lookalike domains**, which need no trickery at all: the attacker validates a name they really own. Your detection layer is Certificate Transparency: every public certificate is logged, so you can watch for certificates for your names that you did not order ([chapter 17](https://pkizerotohero.com/handbook/certificate-transparency/)). ## At work - Developer - IT ops ### How can I see which validation a certificate has? Read its certificate policies. These three real certificates were fetched in October 2026: ```bash openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org /dev/null \ | openssl x509 -noout -subject -ext certificatePolicies ``` ```text subject=CN=letsencrypt.org X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 ``` ```text subject=C=US, ST=California, L=San Francisco, O=Netlify, Inc, CN=*.netlify.app X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS ``` ```text subject=jurisdictionC=US, jurisdictionST=Utah, businessCategory=Private Organization, serialNumber=5299537-0142, C=US, ST=Utah, L=Lehi, O=DigiCert, Inc., CN=www.digicert.com X509v3 Certificate Policies: Policy: 2.16.840.1.114412.2.1 Policy: 2.23.140.1.1 CPS: http://www.digicert.com/CPS ``` The first is DV: a CN and nothing else. The second is OV, with the company and its location. The third is EV, with the jurisdiction, business category and registration number. The CA’s own policy OID (here `2.16.840.1.114412.2.1`) can appear next to the CA/Browser Forum one. ### How do I read CAA records? With `dig` on Linux, macOS or WSL: ```text $ dig CAA google.com +short 0 issue "pki.goog" $ dig CAA www.google.com +short $ dig CAA letsencrypt.org +short 0 issuewild "pki.goog" 0 issue "www.digicert.com" 0 issue "sectigo.com" 0 issue "amazon.com" 0 issuewild "letsencrypt.org" 0 issue "letsencrypt.org" 0 issuewild "www.digicert.com" 0 issuewild "sectigo.com" 0 issuewild "amazon.com" 0 issuewild "ssl.com" 0 issue "pki.goog" 0 issue "ssl.com" ``` `google.com` allows one CA. `www.google.com` returns nothing, so a CA climbs to `google.com` and applies its record. `letsencrypt.org` allows six CAs, for normal and wildcard certificates. The leading `0` is the flags field: no critical properties. On Windows, neither `nslookup` nor `Resolve-DnsName` knows the CAA type (`nslookup -type=CAA` answers `unknown query type: CAA`). Use `dig` in WSL, or a DNS-over-HTTPS service: ```bash curl -s -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=google.com&type=CAA" ``` ```text {"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"google.com","type":257}],"Answer":[{"name":"google.com","type":257,"TTL":86400,"data":"0 issue \"pki.goog\""}]} ``` ### How do I write a CAA policy? In zone-file syntax, a domain that uses only Let’s Encrypt and never wants wildcards could publish: ```text example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issuewild ";" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com" ``` - The first line allows Let’s Encrypt to issue normal certificates for `example.com` and every name below it that has no CAA records of its own. - The second line forbids wildcard certificates from any CA. - The third line asks CAs to report refused requests. Before you publish, list every CA that your teams, CDNs and cloud services really use. A missing CA does not break existing certificates, but the next renewal from that CA fails. The identifier for each CA, such as `letsencrypt.org` or `pki.goog`, is in that CA’s documentation. ### How do I prepare for each ACME challenge? - **HTTP-01**: port 80 must be reachable from the internet, on every server that answers for the name. Let’s Encrypt follows redirects, up to 10 of them, to HTTP or HTTPS on ports 80 or 443, so a redirect to HTTPS is fine. A firewall that blocks port 80 breaks this challenge. - **DNS-01**: your ACME client needs credentials for your DNS provider’s API. Limit them to TXT records, or delegate the challenge with a CNAME from `_acme-challenge.example.com` to a zone used only for validation. Allow for DNS propagation time. - **TLS-ALPN-01**: useful when only port 443 is open. It needs a TLS server or proxy that supports `acme-tls/1`. When validation fails, the ACME client usually prints the CA’s reason: wrong file content, timeout, missing TXT record, or a CAA record that does not list the CA. The full ACME flow, renewal and rate limits are in [chapter 20](https://pkizerotohero.com/handbook/acme/). ### Check a certificate’s validation type yourself Load a certificate into the decoder and look at its policies and subject fields: *Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))* A DV certificate shows the policy `2.23.140.1.2.1` and usually no organisation. Paste your own public certificate to see which type you have. ## Common mistakes - **“The padlock means the site is safe.”** It means the connection is encrypted and goes to the name shown. Phishing sites use valid certificates for their own names. - **“EV stops phishing.”** Users rarely notice EV details, and browsers no longer show them in the address bar. EV also cannot stop a lookalike domain with its own certificate. - **“DV certificates have weaker encryption.”** The encryption is identical. Only the identity checks behind the certificate differ. - **“CAA protects visitors from rogue certificates.”** Clients never check CAA. It is an instruction to CAs at issuance time, honoured by CAs that follow the rules. - **“I can get a wildcard with HTTP-01.”** You cannot. Wildcards need a DNS-based method. - **“Validation is done once.”** CAs may reuse a validation only for a limited time, and that time is shrinking. ## Why it matters to the business - Leader Why it matters to the business Your DNS account can issue certificates in your name A public CA will issue a certificate to whoever controls your domain’s DNS or website at that moment. That makes your registrar and DNS accounts as sensitive as the certificates themselves. Three decisions follow: protect those accounts with multi-factor authentication and a short list of people; publish CAA records that name only the CAs you use; and monitor Certificate Transparency logs for certificates you did not order. Paying for OV or EV adds paperwork, not stronger protection for your visitors, so decide based on contracts or regulation, not security. ## Check yourself Check yourself You need a certificate for \*.example.com from Let's Encrypt. Which challenge must you use? 1. HTTP-01 2. DNS-01 3. TLS-ALPN-01 Show answer Answer B DNS-01 What happened DNS-01 is the only one of the three that can validate a wildcard. Why A wildcard covers names that may not exist yet, so the Baseline Requirements do not allow website or TLS-ALPN methods for it. The rule Wildcards need DNS-based validation. Check yourself A phishing site at a lookalike name shows a valid certificate and the normal browser icon. How did it get the certificate? 1. It stole a certificate from the real bank 2. It proved control of its own lookalike name and received a DV certificate 3. The browser forgot to check the certificate Show answer Answer B It proved control of its own lookalike name and received a DV certificate What happened The attacker passed domain validation for a name they really control. Why DV checks control of the name, not the honesty or identity of the owner. The rule A valid certificate proves the name, not the intent. Check the name itself. Check yourself Your domain's only CAA record allows letsencrypt.org to issue. A team orders a certificate for the same domain from another public CA. What happens? 1. The other CA must refuse to issue 2. Browsers block the certificate 3. Nothing; CAA is only a recommendation for website owners Show answer Answer A The other CA must refuse to issue What happened The other CA must refuse, because CAA does not list it. Why Public CAs must check CAA before issuing. Browsers do not check CAA. The rule CAA controls issuance at CAs. It is not checked by clients. ## Go deeper - [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/), section 3.2.2.4: every allowed domain validation method, and which may validate wildcards. - [CA/Browser Forum EV Guidelines](https://cabforum.org/working-groups/server/extended-validation/guidelines/): what a CA must verify for an EV certificate. - [RFC 8555, section 8](https://www.rfc-editor.org/rfc/rfc8555#section-8): the ACME HTTP-01 and DNS-01 challenges in detail. - [RFC 8737](https://www.rfc-editor.org/rfc/rfc8737): the TLS-ALPN-01 challenge. - [RFC 8659](https://www.rfc-editor.org/rfc/rfc8659) and [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657): CAA records, and the `accounturi` and `validationmethods` extensions. - [Let’s Encrypt: Challenge Types](https://letsencrypt.org/docs/challenge-types/): practical pros and cons of each challenge. The crash course covers validation in [lesson 5, Names, jobs and asking for a certificate](https://pkizerotohero.com/course/names-and-requests/). **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/handbook/domain-validation/). Last reviewed 20 October 2026Edition 0.9 ## Keep going Crash course: [Lesson 5: Names, jobs and asking for a certificate](https://pkizerotohero.com/course/names-and-requests/) ### How-to guides - [How to get and renew Let's Encrypt certificates with certbot](https://pkizerotohero.com/guides/certbot-lets-encrypt/) - [How to automate certificates in Kubernetes with cert-manager](https://pkizerotohero.com/guides/kubernetes-cert-manager/) - [How to automate certificates on Windows with win-acme](https://pkizerotohero.com/guides/win-acme-windows/) - [How to get a wildcard certificate with DNS-01](https://pkizerotohero.com/guides/wildcard-dns-01/) - [How to set CAA records for your domain](https://pkizerotohero.com/guides/caa-records/) - [How to monitor Certificate Transparency for your domains](https://pkizerotohero.com/guides/monitor-certificate-transparency/) ### Tools - [Certificate decoder](https://pkizerotohero.com/tools/decoder/): Paste a PEM certificate and read every field in plain words. ### Topics - [Certificates](https://pkizerotohero.com/topics/certificates/) - [Lifecycle and automation](https://pkizerotohero.com/topics/lifecycle-and-automation/)