Domain validation

Domain Validation (DV) is the fastest and most accessible type of TLS certificate issuance, where a Certificate Authority confirms only that the applicant controls the domain, nothing more. No company identity, no physical address, no legal registration. For millions of websites, this is exactly what the situation requires.

What Domain Validation Actually Verifies

A DV certificate answers one question: does the person requesting this certificate control the domain in question?

The Certificate Authority checks control through one of three standardized methods defined by the CA/Browser Forum:

• Email validation - the CA sends a confirmation message to a predefined address such as admin@, hostmaster@, or postmaster@ at the domain
• DNS CNAME record - the applicant adds a specific token to their DNS zone, proving zone editing access
• HTTP file placement - the applicant uploads a challenge file to a specific path on the web server

Once any one method succeeds, issuance proceeds. In automated environments using ACME protocol (Let's Encrypt, ZeroSSL), the entire process completes in under 90 seconds.

DV vs OV vs EV: What Actually Changes

The visual padlock in browsers looks identical across all three types. Users cannot distinguish a DV certificate from an EV certificate by looking at the browser bar in Chrome or Firefox since 2019, when extended validation green bars were removed.

When DV Is the Right Choice

DV certificates are appropriate when:

• The site collects no sensitive user data (no login, no payment, no personal information)
• The primary need is encrypted transport, not identity assurance
• Automated certificate lifecycle management is already in place (ACME, CI/CD pipelines)
• The organization runs internal tools, staging environments, or developer sandboxes
• Speed of deployment matters more than organizational credibility signaling

Concrete examples: a static marketing blog, a documentation site, an internal API endpoint behind a VPN, a development environment mirror, a content delivery subdomain.

When DV Is the Wrong Choice

Several scenarios make DV certificates technically or regulatorily insufficient:

Financial services in Canada. OSFI guidance and FINTRAC compliance frameworks expect demonstrable identity assurance for customer-facing digital infrastructure. A DV certificate on a banking portal does not satisfy relying party requirements under Canada's financial sector oversight.

PSD2 and eIDAS-regulated contexts. If a Canadian fintech operates with EU partners or processes EU customer data under Open Banking frameworks, PSD2 requires Qualified Website Authentication Certificates (QWACs). QWACs are EV-class certificates issued by EU Trust List providers. A DV certificate cannot substitute for a QWAC regardless of the technical encryption strength.

Digital identity services. Canadian digital identity frameworks, including Pan-Canadian Trust Framework (PCTF) and provincial identity programs, require higher assurance levels for services operating at Identity Assurance Level 2 (IAL2) and above. DV provides IAL1 at best.

API connections in open banking. When a Third Party Provider (TPP) connects to a bank's API under open banking regulation, mutual TLS with certificates carrying verified organizational identity is standard. The bank's API gateway rejects DV certificates in these configurations.

How DV Certificate Issuance Works Step by Step

1. Generate a Certificate Signing Request (CSR) on your server with the domain name(s) included
2. Submit the CSR to a Certificate Authority
3. Choose a validation method: email, DNS, or HTTP
4. Complete the challenge within the CA's time window (typically 24-72 hours, though usually completed in minutes)
5. Receive the signed certificate and intermediate chain
6. Install on the web server and configure HTTPS redirect
7. Set a renewal reminder or configure auto-renewal via ACME

With Let's Encrypt and Certbot on a standard Linux server, steps 2 through 7 are automated in a single command. Renewal happens automatically every 60 days (certificates are valid 90 days).

Certificate Validity Periods in 2026

The CA/Browser Forum voted to reduce maximum TLS certificate validity to 47 days by 2027, with intermediate steps already in force. As of 2026:

This shift makes automated renewal mandatory in practice. Organizations relying on manual DV certificate installation will face increasing operational overhead. Migrating to ACME-based automation before the 47-day limit takes effect is a concrete infrastructure task, not a future consideration.

Wildcard and Multi-Domain DV Certificates

DV certificates support both wildcard and Subject Alternative Name (SAN) configurations:

Wildcard DV - covers *.domain.ca, protecting all single-level subdomains. DNS-01 challenge is required for wildcard validation; HTTP-01 and email methods do not apply.

Multi-domain (SAN) DV - covers a list of specific domains and subdomains in one certificate. Useful for managing multiple properties without separate certificates per domain.

Let's Encrypt caps SAN certificates at 100 domains per certificate. Commercial CAs vary but commonly allow 250 or more SANs.

Security Limitations of DV Certificates

DV certificates do not protect against:

• Phishing domains - An attacker registers paypa1.ca and obtains a valid DV certificate. The certificate is technically legitimate. HTTPS padlock appears. Users may not notice the typosquatted domain.
• Compromised DNS providers - If an attacker gains access to a domain's DNS zone, they can complete DNS-01 validation and issue a certificate for the domain without the legitimate owner's knowledge. Certificate Transparency logs are the primary detection mechanism.
• BGP hijacking during HTTP validation - HTTP-01 challenges can be intercepted if a network-level attacker diverts traffic before the CA's validation request reaches the legitimate server.

Certificate Transparency (CT) logs, monitored through tools like crt.sh or commercial CT monitoring services, allow domain owners to detect unauthorized certificate issuance within minutes of it occurring.

Monitoring and Certificate Transparency

All publicly trusted DV certificates are logged to CT logs by CA requirement. This means:

• Every certificate issued for your domain is publicly visible
• Unauthorized issuance is detectable
• Historical certificate data is searchable

Recommended practice: set up CT log monitoring for your primary domains. Free options include crt.sh email alerts. Commercial options from certificate management platforms provide alerting with SLA-backed response times.

DV Certificates in a Broader TLS Strategy

For organizations managing more than a handful of domains, DV certificates are typically part of a tiered certificate strategy:

This tiering ensures certificate cost and administrative effort are proportional to the trust requirements of each asset.