What Is a Domain Validated (DV) Certificate? DV vs OV vs EV Explained

Most organizations run into domain validated DV certificates the first time they put a website on HTTPS. They are cheap and fast, often issuing in minutes. But DV certificates are not as simple as they appear, and anyone who uses them needs to understand both their benefits and their limitations.

This post covers what a DV certificate is, how the domain validation process works, and how DV compares to OV and EV certificates. We’ll also explore how to authenticate users and devices on your network, and we’ll explain why DV certificates are the wrong tool for 802.1X, EAP-TLS, and VPN authentication.

What Is a Domain Validated (DV) Certificate?

A domain validated (DV) certificate is a TLS/SSL certificate issued by a public certificate authority (CA) after the CA verifies that the applicant controls the domain name listed in the certificate. The CA checks domain control and nothing else. It does not verify the organization’s name, physical address, legal registration, or anything about the people or devices that will use the domain.

When a browser visits a site secured with a DV certificate, it establishes an encrypted TLS session and displays the padlock icon. The padlock means the connection is encrypted. It does not mean the CA investigated who runs the site.

That distinction is worth holding onto. DV certificates are defined by what the CA checked before signing, and what it explicitly did not check. The certificate contains the domain name and the public key. It does not contain an organization name verified through a business registry, an individual’s name, or any attributes tied to internal users or devices. Two other certificate types, OV and EV, require progressively deeper vetting before issuance.

How Domain Validation Works

Domain validation is automated. The applicant generates a Certificate Signing Request (CSR) and selects a validation record. A public certificate authority confirms control of a domain using one of three validation methods. The CA then attempts to verify control. Once verified, the CA signs and issues the certificate, typically within minutes to a few hours.

Email Validation

The CA sends a verification email to a listed administrative contact address, one of the standard addresses (admin@, hostmaster@, postmaster@, webmaster@, or administrator@ at the domain), or to a contact listed in a CAA or DNS TXT record. The applicant clicks a link or replies with a code to confirm control.

HTTP File Validation

The CA generates a random token and instructs the applicant to place a text file containing that token at a specific path on the web server in a format like http://example.com/.well-known/acme-challenge/[token]. The CA then fetches that URL. If the file is present and correct, domain control is confirmed.

DNS/CNAME Validation

The CA provides a specific CNAME or TXT record value. The applicant adds it to their DNS zone. The CA queries DNS and confirms the record exists. This method works well for wildcard certificates and for organizations that manage DNS programmatically.

The validation process proves only that the applicant can respond through the domain. However, it tells the CA nothing about who controls it, what organization it belongs to, or who works there.

DV vs OV vs EV Certificate: Full Comparison

DV, OV, and EV certificates all use the same TLS encryption. A connection secured with a DV certificate is encrypted with the same key strength as one secured with an EV certificate.

The differences between DV, OV, and EV certificates are in what the CA verified about the entity before issuing the certificate, and what identity information appears in the certificate itself.

All three certificate types encrypt traffic equally well. The distinction is what the CA verifies about the entity before signing the certificate, and what identity fields appear in the certificate.

One point worth noting: EV certificates once displayed the organization name in a green address bar. That visual indicator was removed from Chrome and Firefox in 2019 after research showed most users did not pay attention to it. Today, all three certificate types use the same padlock icon and look identical in the browser.

When to Use Each Certificate Type

Choosing between DV, OV, and EV comes down to what level of identity verification matters for your use case and who is checking.

When DV Is the Right Choice

DV certificates fit well for contexts where domain-level trust is sufficient, such as:

• Personal websites and blogs with no user login or payment processing
• Development and staging environments where you need TLS but not identity vetting
• Internal APIs consumed by your own software where you control both ends
• Open source project documentation or informational sites

Speed and cost are also relevant factors. Let’s Encrypt issues free DV certificates through an automated API (the ACME protocol) in seconds. For high-volume scenarios such as protecting dozens of subdomains or rotating certificates on short cycles, DV automation is the practical default.

When OV Makes Sense

OV certificates are appropriate when the organization’s identity in the certificate adds meaningful assurance, in environments like:

• Customer-facing web applications where buyers might inspect certificate details
• B2B SaaS login pages and purchase flows
• Compliance environments that require OV or higher (some government procurement standards specify this)
• Scenarios where phishing impersonation is a concern and certificate details are one mitigation layer

The vetting process takes 1–3 days, which may be a problem for some workflows. However, OV certificates confer a high degree of trust, since organization names appears in the certificate details and are visible to anyone who inspects the certificate directly.

When EV Is Warranted

EV certification makes sense for high-stakes, high-assurance contexts like:

• Banking and financial services applications
• Healthcare patient portals subject to HIPAA or similar requirements
• High-value e-commerce where phishing is an active threat and certificate details are audited

EV requires the most extensive verification of all three certificate types. During EV verification, the CA confirms legal registration, physical address, phone number, and jurisdiction.

EV is also the most expensive and slowest option. Given that browsers no longer display the EV indicator prominently, the practical security benefit over OV has narrowed for most use cases.

What DV Certificates Cannot Do

Any IT team responsible for network authentication should have a solid understanding of the gaps in DV certificate capabilities. Unfortunately, almost every article on domain validated DV certificates skips this topic.

DV certificates carry no user identity. The subject field contains the domain name, but there is no username, no email address, and no employee record. A certificate for example.com identifies the domain, rather than any individual who works at the organization that owns it.

Likewise, DV certificates carry no device identity. There is no device serial number, no hardware identifier, and no MDM enrollment status. Nothing in a public DV certificate distinguishes an authorized employee laptop from a personal device or an attacker’s machine.

DV Certificates and 802.1X Authentication

DV certificates do not work for 802.1X certificate-based authentication.

When an endpoint connects to an 802.1X network using EAP-TLS, the RADIUS server must validate that the presented certificate identifies a specific, authorized user or device. It compares the certificate’s Subject or Subject Alternative Name fields against a directory like Entra ID, Okta, Google Workspace, or LDAP.

A public DV certificate for your company’s domain has no matching record in that directory, because it carries no user or device identity.

The same constraint applies to VPN certificate authentication and to client certificate authentication for web applications. The certificate must identify the entity making the connection, not just the domain name associated with an organization.

The RADIUS server does not care whether a certificate was issued for “yourcompany.com.” It checks whether the certificate subject identifies a specific, authorized user or device in your directory.

Public DV, OV, and EV certificates are issued by third-party CAs for the purpose of securing web traffic between browsers and servers. They are not designed to carry internal organizational identity attributes. That is a separate problem, and it requires a different class of certificate infrastructure.

Why Enterprise Networks Need Private PKI Certificates

Organizations that authenticate users and devices over 802.1X, EAP-TLS, or VPN use private PKI, a certificate authority operated or managed by the organization itself, issuing certificates that carry organization-specific identity attributes.

A private CA issues certificates where the Subject and Subject Alternative Name (SAN) fields are populated directly from the organization’s identity provider. That means a device certificate might carry:

• The device’s hostname or serial number (from MDM enrollment)
• The user’s UPN or email address (from Entra ID or Okta)
• Group membership or department (from directory attributes)

When that certificate is presented to a RADIUS server during 802.1X authentication, the server looks up those attributes in real time against the IdP.

If the user is active and the device is enrolled, access is granted. If the user is offboarded or the device is removed from MDM, the lookup fails and access is immediately denied, without any password to reset or token to revoke.

This is certificate-based authentication in practice: access decisions tied to live identity and device state, not to the knowledge of a shared secret.

Public DV, OV, and EV certificates issued by commercial CAs cannot carry these attributes. The CA does not have access to your directory. The certificate authority for enterprise network auth must be integrated with the identity layer, which is what private PKI provides.

SecureW2 managed PKI provides exactly this infrastructure. The SecureW2 platform acts as a private CA integrated directly with Entra ID, Okta, and Google Workspace. Certificates issued through the JoinNow Platform carry the identity attributes required for 802.1X and EAP-TLS authentication, and JoinNow Cloud RADIUS validates those certificates with real-time IdP lookups at every connection attempt.

For managed devices, enrollment is automated through Intune, Jamf, Kandji, and Google Workspace MDM. For unmanaged and BYOD devices, JoinNow MultiOS provides a self-service onboarding flow that configures the device and provisions the certificate without IT intervention.

How to Get a DV Certificate

For web-facing TLS, the two most common paths to getting a DV certificate are as follows:

Let’s Encrypt

Let’s Encrypt issues free DV certificates using the ACME protocol. Certificates are valid for 90 days and must be renewed automatically — the ACME client handles this. Certbot is the most widely used ACME client for web servers. Let’s Encrypt is DV-only by design; they explicitly do not issue OV or EV certificates because those require manual human review that cannot be automated at their scale.

Commercial CAs

Commercial CAs offer paid DV certificates with longer validity periods. They remain valid for 200 days under current CA/Browser Forum rules, with planned reductions to a 47-day validity period by March 2029. Commercial DV certs are appropriate when the hosting environment does not support automated ACME renewal, or when a specific CA is required by a compliance policy.

For both Let’s Encrypt and commercial CAs, the workflow is:

1. Generate a private key and CSR on the web server.
2. Submit the CSR to the CA and complete one of the three domain validation methods described above.
3. Download and install the issued certificate and intermediate chain.
4. Configure the web server to serve the certificate on port 443.
5. Set up automated renewal (strongly recommended — ACME clients handle this natively).

If the goal is enterprise network authentication rather than web TLS, the path is different. See the section above on private PKI and the SecureW2 managed PKI page for deployment details.

Add Certificate-Based Identity to Your Network with SecureW2

DV certificates do exactly what they were designed to do: prove domain ownership and enable TLS encryption for web traffic. They are not designed to identify users or devices on a corporate network, and no amount of certificate tier upgrading changes that. OV and EV certificates are also public CA products, and they carry the same fundamental limitation for network auth: no private identity attributes.

The infrastructure that secures 802.1X networks, EAP-TLS VPNs, and enterprise Wi-Fi is private PKI, or certificates issued by a CA that knows your users, your devices, and your access policies. Private PKI also revokes access the moment an account is disabled or a device falls out of compliance.

SecureW2 managed PKI provides secure infrastructure you need as a cloud-native service. Our platform issues certificates tied to live user and device identity from your IdP, including Entra ID, Okta, and Google Workspace.Our Cloud RADIUS validates those certificates at every connection attempt with a real-time identity lookup. Managed device enrollment runs through Intune, Jamf, Kandji, and Google Workspace MDM. BYOD enrollment runs through the JoinNow MultiOS self-service flow, with no IT involvement required.

Schedule a demo to see how SecureW2 private PKI and Cloud RADIUS replace password-based Wi-Fi and VPN authentication, or contact SecureW2 to discuss your specific network authentication requirements.