Types of SSL certificates: DV, OV, EV, Wildcard — which one to choose

Choosing an SSL certificate is no longer a formality. In 2026 year, the certificate type affects more than just whether a padlock appears in the address bar: it also affects search rankings, user trust, and compliance with regulatory requirements. The market offers dozens of options, from free DV certificates to EV certificates costing hundreds of dollars. Let’s look at how they differ and which one is right for your project.

Why you need an SSL certificate

Data security

An SSL/TLS certificate encrypts data between the browser and the server. Without one, anyone with access to an intermediate point in the network—a provider, public Wi-Fi administrator, or attacker—can intercept transmitted information such as usernames, passwords, and bank card details.

A certificate serves two functions:

• Authentication — confirms that the server actually belongs to the stated owner
• Encryption — establishes a secure channel using session keys

SEO impact

Google included HTTPS as a ranking factor back in 2014 year. Since then, the importance of this signal has only grown:

• Browsers mark sites without HTTPS as “Not secure,” increasing the bounce rate
• Google Search Console displays warnings for pages with mixed content
• Core Web Vitals require a stable HTTPS connection for accurate metric measurement
• HTTP/2 and HTTP/3, which speed up loading, work only over TLS

You can check the certificate’s current status using reChecker’s SSL Checker—the tool shows the certificate type, expiration date, trust chain, and potential issues.

User trust

According to GlobalSign, 84% of users will refuse to make a purchase on a site if they see an insecure connection warning. For e-commerce and financial services, SSL is a prerequisite for payment gateway operation. The PCI DSS standard expressly requires encryption of all data related to card processing.

Types by validation level

All SSL certificates provide the same level of encryption. They differ in how thoroughly the owner is validated and how much information the certificate includes.

DV — Domain Validation

The simplest type. The certificate authority (CA) verifies domain ownership using one of the following methods:

• Placing a special file in the .well-known directory on the server
• Creating a TXT or CNAME DNS record
• Replying to an email sent to admin@, webmaster@, or hostmaster@ at the domain

Issuance takes anywhere from a few seconds to a few minutes. The certificate contains only the domain name, with no organization information.

Suitable for: personal sites, blogs, landing pages, small projects, and internal services.

OV — Organization Validation

In addition to the domain, the CA verifies that the organization exists and is legitimate:

• Checking the legal entity’s registration details in government registries
• Verifying the organization’s physical address
• Confirming the phone number through a callback
• Verifying that the applicant is authorized to act on behalf of the organization

The certificate includes the company name, city, and country—this information is visible when viewing the certificate details in a browser.

Suitable for: corporate websites, business portals, SaaS platforms, and government agencies.

EV — Extended Validation

The highest level of validation. The process is governed by CA/Browser Forum standards:

• Everything required for OV
• Verification of the company’s legal and operational existence
• Confirmation of physical presence (not a P.O. Box)
• Verification of the applicant’s authority
• Checks against independent sources (Dun & Bradstreet, government registries)

EV certificates used to display the company name in the address bar (a green bar). Since 2019 year, Chrome and Firefox have removed this indicator, but the information is available by clicking the padlock.

Suitable for: banks, payment systems, large online stores, and insurance companies.

Comparison table by validation level

You can find out the certificate type of any website from the command line:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -text | grep -A2 "Subject:"

For DV, the output contains only CN = example.com. For OV and EV, it also includes the fields O = (organization), L = (city), and C = (country).

Types by number of domains

Single Domain

Protects one specific domain. Most CAs include both the www and non-www versions:

example.com
www.example.com

The most affordable option. Suitable for projects with one domain and no subdomains.

Wildcard

Protects a domain and all its first-level subdomains using the *.example.com pattern:

example.com
*.example.com  →  mail.example.com, shop.example.com, api.example.com

Limitation: a Wildcard certificate does not cover second-level subdomains. dev.api.example.com requires a separate certificate or a Multi-Domain Wildcard.

Multi-Domain (SAN / UCC)

Protects several different domains with one certificate using the Subject Alternative Name (SAN) extension:

example.com
example.org
shop.another-domain.com

The base price usually includes 3–5 domains, with the option to add up to 100–250 more. It is often used for Microsoft Exchange, Office 365, and multi-domain services.

Multi-Domain Wildcard

A combination of Multi-Domain and Wildcard: one certificate protects multiple domains along with their subdomains. This is the most flexible and most expensive option (from $200/year).

Comparison table by coverage type

Free vs. paid certificates

Free CAs

Let’s Encrypt is the most popular free CA. Features:

• DV certificates only, with a validity period of 90 days
• Supports Wildcard certificates through the DNS-01 challenge
• Fully automated through the ACME protocol
• No warranty or customer support

ZeroSSL is an alternative with a web interface: free for up to 3 certificates for 90 days; it offers ACME and a REST API, as well as paid plans with Wildcard certificates and monitoring.

Google Trust Services offers free DV certificates through ACME, with Google Cloud integration.

Paid CAs

When it is worth paying

Free DV is sufficient for most projects. A paid certificate is justified if:

1. OV or EV is required — no free options are available
2. A financial warranty is needed — warranty from $10K to $2M in case of compromise
3. Technical support matters — a dedicated support line
4. There are regulatory requirements — finance, healthcare, or the public sector
5. Corporate management is needed — a centralized dashboard for hundreds of certificates, an API, and role-based access

How to choose: decision matrix

By project type

Selection process

1. Обрабатываете платежи напрямую?
   ├── Да → EV или OV + Multi-Domain
   └── Нет → п.2

2. Требуется идентификация организации?
   ├── Да → OV
   └── Нет → DV

3. Сколько доменов/поддоменов?
   ├── 1 домен, без поддоменов → Single Domain
   ├── 1 домен + поддомены → Wildcard
   ├── Несколько доменов → Multi-Domain (SAN)
   └── Несколько доменов + поддомены → Multi-Domain Wildcard

4. Бюджет критичен?
   ├── Да → Let's Encrypt
   └── Нет → коммерческий CA

How to obtain each type

DV through Let’s Encrypt (Certbot)

sudo apt update && sudo apt install certbot

# Для Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Для Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Wildcard (DNS-верификация)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d "*.example.com"

# Автоматическое продление
sudo certbot renew --dry-run

For a Wildcard certificate, Certbot will ask you to create a TXT record _acme-challenge.example.com. The certificate will be issued after DNS verification.

DV through acme.sh

An alternative ACME client that works without root access:

curl https://get.acme.sh | sh -s email=admin@example.com

# Через webroot
acme.sh --issue -d example.com -w /var/www/html

# Wildcard через Cloudflare DNS API
export CF_Token="your_token"
acme.sh --issue -d example.com -d "*.example.com" --dns dns_cf

# Установка для Nginx
acme.sh --install-cert -d example.com \
  --key-file /etc/ssl/private/example.com.key \
  --fullchain-file /etc/ssl/certs/example.com.crt \
  --reloadcmd "systemctl reload nginx"

OV/EV certificate

The process is fundamentally different—full automation is not possible:

1. Generate a CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=My Company LLC/CN=example.com"

2. Submit the CSR to the CA through its web dashboard or API
3. Complete validation — the CA will contact the organization and request documents
4. Receive and install the certificate

For EV, you will also need the organization’s founding documents, proof of the applicant’s authority, and a callback to the organization’s publicly listed phone number.

Server configuration

Nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/certs/chain.crt;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    root /var/www/example.com;
    index index.html;
}

Apache

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/chain.crt

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder off

    SSLUseStapling on
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

SSLStaplingCache shmcb:/var/run/ocsp(128000)

Verification after installation

# Проверка конфигурации
sudo nginx -t                # Nginx
sudo apachectl configtest    # Apache

# Информация о сертификате
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -text

# Срок действия
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates

# Цепочка сертификатов
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null

In addition to manual verification, it is useful to test the certificate with reChecker’s SSL Checker—the tool detects an incomplete trust chain, outdated protocols, weak ciphers, and SAN errors.

Also check your security headers—especially HSTS—to make sure browsers are forced to use HTTPS.

Expiration monitoring

An expired certificate is one of the most common reasons a website becomes unavailable. Browsers completely block access to these resources and show a frightening warning.

Check with openssl

# Срок действия
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -enddate

# Дней до истечения
EXPIRY=$(echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ($(date -d "$EXPIRY" +%s) - $(date +%s)) / 86400 ))
echo "Дней до истечения: $DAYS"

Monitoring script for multiple domains

#!/bin/bash
DOMAINS=("example.com" "shop.example.com" "api.example.com")
WARN=30; CRIT=7

for d in "${DOMAINS[@]}"; do
  exp=$(echo | openssl s_client -connect "$d:443" -servername "$d" 2>/dev/null | \
    openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  [ -z "$exp" ] && echo "[ОШИБКА] $d — сертификат недоступен" && continue

  left=$(( ($(date -d "$exp" +%s) - $(date +%s)) / 86400 ))
  if [ "$left" -le "$CRIT" ]; then
    echo "[КРИТИЧНО] $d — $left дн."
  elif [ "$left" -le "$WARN" ]; then
    echo "[ВНИМАНИЕ] $d — $left дн."
  else
    echo "[OK] $d — $left дн."
  fi
done

Run it from cron with an email notification:

0 9 * * * /opt/scripts/ssl-check.sh 2>&1 | grep -v "\[OK\]" | mail -s "SSL Alert" admin@example.com

Automated monitoring

For continuous monitoring, use specialized tools:

• SSL monitoring on reChecker — automated checks with notifications about approaching expiration dates
• Prometheus + blackbox_exporter — for integration into existing monitoring
• Uptime Kuma — a self-hosted solution with SSL-checking support

Example Prometheus alert:

groups:
  - name: ssl
    rules:
      - alert: SSLCertExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "SSL-сертификат {{ $labels.instance }} истекает через {{ $value | humanizeDuration }}"
      - alert: SSLCertExpiryCritical
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 7
        for: 1h
        labels:
          severity: critical

CAA records in DNS

An SSL certificate is part of the overall security infrastructure. Check your DNS records with DNS Lookup to make sure CAA records are present:

dig CAA example.com

# Ожидаемый результат для Let's Encrypt:
# example.com.  IN  CAA  0 issue "letsencrypt.org"
# example.com.  IN  CAA  0 issuewild "letsencrypt.org"

CAA restricts which CAs can issue certificates for your domain, providing additional protection against unauthorized issuance.

Common errors and how to fix them

NET::ERR_CERT_AUTHORITY_INVALID

The certificate chain is incomplete—the server is sending the end-entity certificate without the intermediate certificates:

cat example.com.crt intermediate.crt > fullchain.crt

Specify fullchain.crt in the ssl_certificate directive (Nginx) or SSLCertificateChainFile directive (Apache).

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The client and server cannot agree on a protocol. Make sure TLS 1.2 and TLS 1.3 are enabled, and that the outdated SSLv3 and TLS 1.0/1.1 are disabled.

Mixed Content

The page loads over HTTPS, but some resources are requested over HTTP:

curl -s https://example.com | grep -oP 'http://[^"'"'"'> ]+'

The solution is to update the resource URLs or add a CSP header upgrade-insecure-requests.

SSL_ERROR_HANDSHAKE_FAILURE_ALERT

Usually associated with an SNI mismatch. If multiple websites are hosted on one IP address, the server must support Server Name Indication to select the correct certificate.

Conclusion

Choosing an SSL certificate comes down to three questions: validation level (DV, OV, EV), number of domains (Single, Wildcard, Multi-Domain), and budget (free Let's Encrypt or a commercial CA).

For most projects, a free DV certificate from Let's Encrypt is sufficient. OV is justified for companies that value organizational identity verification. EV remains the choice for financial services where the highest level of trust is critical.

Two rules never change: set up automatic renewal (an expired certificate is worse than having none) and monitor its status through SSL monitoring or your own scripts, so you find out about problems before users do. Properly configured SSL is the foundation of your project's security, trust, and SEO rankings.