Proving you own the name: DV, OV, EV and CAA

Anyone can send a CA a request for any name. In chapter 10 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.

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 in DNS. It lists which CAs may issue certificates for the name. Every public CA must check it before issuing.

What do DV, OV and EV actually check?

The Baseline Requirements (BRs) of the CA/Browser Forum set the rules for DV, OV and the less common IV (individual validated). The EV 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:

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). That binding means only your account can use a passed challenge.

• HTTP-01 (section 8.3): you serve the key authorization at http://<name>/.well-known/acme-challenge/<token>. The CA fetches it over plain HTTP on port 80.
• DNS-01 (section 8.4): you publish a TXT record at _acme-challenge.<name>, holding the base64url SHA-256 hash of the key authorization.
• TLS-ALPN-01 (RFC 8737): 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.

Swipe sideways to see the whole diagram.

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 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 (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).

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): 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). And it binds honest CAs, so it cannot stop a CA that ignores the rules. RFC 8657 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).

How can I see which validation a certificate has?

Read its certificate policies. These three real certificates were fetched in October 2026:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext certificatePolicies

subject=CN=letsencrypt.org
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.2.1

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

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:

$ 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:

curl -s -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=google.com&type=CAA"

{"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:

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.

Check a certificate’s validation type yourself

Load a certificate into the decoder and look at its policies and subject fields:

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

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.

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, section 3.2.2.4: every allowed domain validation method, and which may validate wildcards.
• CA/Browser Forum EV Guidelines: what a CA must verify for an EV certificate.
• RFC 8555, section 8: the ACME HTTP-01 and DNS-01 challenges in detail.
• RFC 8737: the TLS-ALPN-01 challenge.
• RFC 8659 and RFC 8657: CAA records, and the accounturi and validationmethods extensions.
• Let’s Encrypt: Challenge Types: practical pros and cons of each challenge.

In the gameLevel 11: Proving you own the nameSurveyors' Office, Keystone. In development

The crash course covers validation in lesson 5, Names, jobs and asking for a certificate.