SSL Certificate Types: Choosing the Right One Between DV, OV, and EV

The browser opens, the padlock icon is crossed out and it says "Not Secure". Or worse: the user sees the message "NET::ERR_CERT_DATE_INVALID" and closes the page. If you're right now on a page where you need to decide between a free DV certificate and a paid OV certificate, this text is for you. The right decision depends on what your site proves to the user, not on the certificate's price.

Three Certificate Levels, Three Levels of Identity Proof

When we say "SSL certificate types", we're actually talking about the level of validation, not about the encryption algorithm. All three levels use the same encryption; the difference is in the process the CA goes through before signing.

• DV (Domain Validation): Only domain ownership is verified. Usually with a DNS TXT record or a file on the web server. Issued within minutes.
• OV (Organization Validation): The legal identity of the organization is verified; company registration, address, phone number. Takes a few business days.
• EV (Extended Validation): Deeper legal and operational verification. It used to activate the green bar in the browser's address bar.

That Green Bar No Longer Exists

If someone told you "buy EV to get the green bar", their information is from 2018. Since Chrome 77 and Firefox 70, browsers removed the green bar display. Now you can only see the organization name by clicking on the padlock. So the "more visual trust" argument for EV is no longer valid. What remains are organizational compliance requirements.

Which Level to Choose for Which Site

Short answer: DV is enough for 90% of sites. If your site is a blog, a small store, or a SaaS and the user doesn't open a bank account with you, get DV and spend the extra money on backups. Choose OV when you have enterprise customers and their legal team wants the certificate on the supplier checklist. Choose EV only when a contract or regulator explicitly requires it.

The Cost Nobody Talks About

OV and EV have a hidden cost: the renewal cycle. Each time, the organizational documents must be re-verified, and if the phone number registered in WHOIS has changed, the process stops. I've seen a site running on an OV certificate stay up for 48 hours with an expired certificate on renewal day due to not responding to the confirmation email. This doesn't happen with DV because verification is automatic.

Verifying the Certificate Chain on the Server

Installing the certificate is half the work. The other half is the correctness of the Intermediate Chain. If the chain is incomplete, desktop browsers may silently ignore it, but mobile apps or curl will throw an error. Check this with a simple command:

openssl s_client -connect example.com:443 -servername example.com -showcerts

In the output, look for the line Verify return code: 0 (ok). If you see a number other than zero, the chain has a problem. To check the expiration date:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

The output gives something like notAfter=Mar 14 12:00:00 2026 GMT. Record this date in your monitoring system, not in a personal calendar.

This Is Where They Make Mistakes

The most common mistake I see: installing the certificate on the main domain and forgetting www. The user opens www.example.com, the certificate was issued for example.com, and the browser gives the error NET::ERR_CERT_COMMON_NAME_INVALID. The sign is also that the site opens on mobile for some users and not for others; because some type with www and some without it. The solution: either get a Wildcard certificate, or add both names in the SAN, or set up a 301 redirect from www to the main domain.

Common Errors and Their Real Root Cause

When the certificate has a problem, the browser message is usually misleading. Keep this quick map handy:

• ERR_CERT_DATE_INVALID: Server clock or certificate date. First check timedatectl status.
• ERR_CERT_AUTHORITY_INVALID: The intermediate chain is incomplete or a self-signed certificate is installed.
• ERR_SSL_PROTOCOL_ERROR: Usually a conflict between the web server and a front proxy that's grabbing traffic on port 443.
• Gray padlock without error: Mixed Content resources; an image or script loaded over http://.

For the last case, open the browser console and look for Mixed Content warnings. If you have a WordPress site, this usually comes from an old plugin that hardcoded the image URLs. The guide WordPress Security; from wp-config to plugins that are themselves vulnerabilities covers exactly this category of problems.

Renewal Automation: What You Should Do from Day One

Today's certificates have a maximum validity of 398 days, and the global trend is moving toward 90 days. That means manual renewal is no longer an option. If you use Let's Encrypt, set up Certbot with a timer:

systemctl list-timers | grep certbot
certbot renew --dry-run

The second command simulates the entire renewal process without making actual changes. If it errors, stop right there; because it will also error on the actual renewal day. Also set up a monitoring alert for 14 days before expiration.

When You Use a CDN or Proxy

If your traffic passes through a middle layer, you have two certificates: one between the user and the edge, one between the edge and the origin server. The common error is that the origin certificate expires but the user sees nothing, because the edge still shows its own valid certificate. Until the day the edge connects to the origin and you get a 526 error. To see the real-time status of services and diagnose where the problem is, real-time service status is a good starting point.

Choosing a CA: What Really Matters

The CA brand makes almost no difference in security. What matters: ACME support for automation, Wildcard support, and a track record of responsiveness in technical support. A cheap CA with good automation is better than an expensive CA with a manual process. If your team has limited resources, take this seriously.

A point that's rarely mentioned: an SSL certificate only covers the transport layer. If your server isn't protected against volumetric attacks, having HTTPS doesn't help at all. Plan DDoS protection separately from the certificate discussion. Also, if your team has SSH access to servers, move forward with SSH Security; from changing the port to fail2ban and public keys in parallel with the certificate work; these two are usually neglected together.

Frequently Asked Questions

Is a DV certificate secure for an online store?

Yes, cryptographically it's no different from OV and EV. All three use TLS with the same strength and user data is encrypted the same way. The difference is only in the level of issuer identity verification. If your payment gateway doesn't have a specific contractual requirement, DV is enough.

Why does the browser still show insecure after installing the certificate?

In most cases it's due to Mixed Content; meaning the main page loads over HTTPS but some resources (image, script, font) are called over http://. Open the browser console and look at the Mixed Content warnings. If it's a certificate error and not Mixed Content, check the intermediate chain with openssl s_client.

What's the difference between a Wildcard and a Multi-Domain certificate?

A Wildcard covers one domain and all subdomains one level deep, like *.example.com. A Multi-Domain (or SAN) gathers several completely different domains into one certificate, like example.com and example.ir and shop.example.net. If you have many subdomains, Wildcard is better; if you have several separate brands, SAN is more suitable.

How often should I renew the certificate?

The maximum allowed validity today is 398 days, but the industry trend is moving toward 90 days. In practice, you should fully automate renewal and just have expiration monitoring. If your team has multiple services, keep documentation and the knowledge base updated to record renewal procedures and ownership of each certificate, so that on the day the person responsible changes, no one is left not knowing which certificate belongs to which service.

If you have a certificate on a server right now, before doing anything else, run this command: echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates -subject. If the expiration date is less than 30 days away or the subject doesn't match the domain the user types, fix that first. The rest of the discussion only makes sense after this step. To set up and manage certificates on your infrastructure, ServerNet security services is an option you can check out.