DV, OV, and EV SSL Certificates Explained: Which One Your Hosting Panel Actually Issues

If your hosting panel hands you a free SSL certificate, you are getting a DV (Domain Validation) certificate — almost certainly from Let's Encrypt. That is not a limitation. It is the right answer for the vast majority of websites. But the fact that DV, OV (Organization Validation), and EV (Extended Validation) certificates all display the same padlock in a 2026 browser creates real confusion: why do OV and EV certificates exist, what do they cost, and when does paying for one actually make sense?

This post answers those questions from two angles. The first section is for site owners, business operators, and anyone who manages websites professionally. The second section is for sysadmins and engineers who want to understand the ACME protocol, challenge methods, and how Panelica's SSL stack actually works. Both sections are complete on their own — jump to whichever matches your context.

Quick summary before we go further: Panelica issues DV certificates (Let's Encrypt) and Cloudflare Origin Certificates (CF Origin CA). It does not resell OV or EV certificates. If you need an OV or EV certificate, you purchase it directly from a commercial CA and then import the cert and key into Panelica manually. The panel accepts any valid cert and key pair. That distinction shapes everything that follows.

Jump to section: For Site Owners and Business Operators | For Sysadmins and SSL Engineers

For Site Owners and Business Operators

What does my hosting panel's free SSL actually give me?

When you click "Issue SSL" in a hosting panel and a certificate appears in under a minute at no cost, you are receiving a DV certificate issued by Let's Encrypt. Let's Encrypt is a non-profit Certificate Authority operated by the Internet Security Research Group. It has issued certificates for hundreds of millions of domains since its public launch in 2016.

What a DV certificate proves: the person who requested it controlled the domain at the time of issuance — either by placing a specific file at a known URL path, or by creating a specific DNS record. That is the entirety of the validation. No business identity is checked. No phone call is made to your company. No letterhead is required.

What a DV certificate provides: full TLS encryption between your visitor's browser and your server. All data in transit is encrypted with the same cipher suites regardless of whether your certificate cost zero dollars or five hundred dollars. A free Let's Encrypt DV certificate and a $500 EV certificate produce identical encryption quality. The difference is in what was verified before issuance, not in the cryptographic strength of the certificate itself.

DV, OV, EV — three certificate tiers that look identical in 2026 browsers

Here is the practical reality that changed everything: in 2019, Chrome 77 (released September 2019) removed the green address bar that had previously shown the company name when an EV certificate was in use. Firefox 70 (October 2019) and Safari 13.1 (March 2020) followed. Today, in every major browser, a site with an EV certificate and a site with a DV certificate display exactly the same padlock icon. The organization name in an EV certificate is still accessible — click the padlock, then look at the certificate details — but it is no longer surfaced visually in the URL bar.

This matters because the primary argument for EV certificates had always been user trust signaling in the browser bar. That argument is effectively gone for general website visitors. The only remaining case for EV is in contexts where the certificate's detailed contents are being read programmatically or inspected by compliance auditors.

When DV is enough (most websites)

Domain Validation certificates are appropriate for the overwhelming majority of websites in 2026. Specifically, DV is sufficient for:

• All personal websites, blogs, and content sites
• E-commerce stores, including those processing card payments — PCI-DSS compliance requires encryption, not OV or EV specifically
• SaaS applications, web apps, and API endpoints
• Corporate informational sites and marketing pages
• Developer tools, dashboards, and internal panels
• Any site where customers authenticate via username/password over HTTPS

If you have uncertainty about whether DV meets a specific compliance requirement, the answer for the most common frameworks is: yes. PCI-DSS 4.0 requires strong TLS encryption, which DV provides. HIPAA Technical Safeguards require encryption of protected health information in transit, which DV provides. SOC 2 trust service criteria address availability and confidentiality — DV satisfies the encryption requirement. None of these frameworks mandate OV or EV certificates.

When OV is worth the price

Organization Validation certificates require the CA to verify your organization's legal existence. The CA checks business registration documents, verifies your physical address, and may phone the number listed in official business directories. Validation takes between one and five business days. A single-domain OV certificate from a commercial CA typically costs between $50 and $200 per year.

The cases where OV adds genuine value are narrower than vendors sometimes suggest, but they do exist:

• B2B software where procurement teams inspect certificates — enterprise buyers purchasing software with sensitive integrations may require that certificate subjects show a verified organization name in the cert detail
• Financial institutions and regulated entities where internal policy or external auditor requirements specify OV
• Organizations that want their legal entity name surfaced in cert details for clients who check the certificate manually — this is niche but legitimate
• Resellers and agencies building client contracts that explicitly specify certificate tier as a deliverable

If none of these apply to you, OV offers no practical benefit over DV for your site visitors.

When EV is worth the price (it almost never is in 2026)

Extended Validation certificates involve the most thorough identity check a commercial CA performs. The CA reviews articles of incorporation, verifies the requesting organization through official business registries, and requires a signed agreement from an authorized representative. Validation takes between seven and fourteen business days. Pricing runs from $150 to $500 and above per year for a single domain.

Before 2019, EV certificates displayed the organization's legal name in the browser's address bar — the "green bar" effect. This was the primary reason enterprises paid the premium. Chrome's removal of the EV indicator in September 2019 fundamentally reduced the consumer-facing value of EV certificates. Ordinary website visitors cannot distinguish an EV site from a DV site by looking at the browser bar.

EV still serves a purpose in a narrow set of contexts:

• Retail banking and financial services where internal security policy mandates EV regardless of browser display changes — often driven by legacy policy documents written before 2019
• Regulatory mandates in specific jurisdictions or industries that specify EV by name in their requirements
• High-value transactional systems where phishing risk mitigation via cert-level identity is part of a layered security strategy, and where technical users are trained to inspect certificate subjects

If you are not in banking, financial services, or a regulated industry with a specific EV requirement, there is no meaningful benefit to an EV certificate in 2026 that justifies the price and the multi-week validation wait.

What Cloudflare's Origin Certificate is, and when it makes sense

A Cloudflare Origin Certificate is a different product category entirely. It is not a publicly trusted certificate — browsers would reject it if presented directly. It is a certificate issued by Cloudflare's own CA, intended for use exclusively on the connection between Cloudflare's edge network and your origin server.

When your site is proxied through Cloudflare, visitor traffic terminates at the Cloudflare edge. Cloudflare then makes a separate connection to your origin server. The Cloudflare Origin Certificate secures that edge-to-origin leg of the connection. The certificate never reaches end users — Cloudflare's publicly trusted certificate handles the browser-to-edge side.

The operational advantage of a Cloudflare Origin Certificate is its validity period. Cloudflare allows Origin Certificates with validity of up to 5475 days — approximately 15 years. Panelica sets this as the default when issuing Origin Certificates through its Cloudflare integration. A certificate that does not expire for 15 years eliminates the renewal burden entirely for the origin-side connection.

When does a Cloudflare Origin Certificate make sense? Only when the domain is actively proxied through Cloudflare. If the domain uses Cloudflare's DNS but the proxy is disabled (DNS-only mode, orange cloud off), Cloudflare's edge does not terminate the connection, and a Cloudflare Origin Certificate will not be presented to anyone. For DNS-only Cloudflare setups, a standard Let's Encrypt DV certificate is the right choice.

Wildcard versus single-domain versus multi-domain certificates

A wildcard certificate uses the common name *.example.com and covers any single-level subdomain: app.example.com, api.example.com, mail.example.com, and so on. It does not cover the root domain example.com itself (most CAs will include the root as a SAN automatically) and it does not cover two-level subdomains like api.staging.example.com.

Wildcard certificates are available as DV, OV, or EV. Let's Encrypt issues free wildcard DV certificates. The critical constraint: Let's Encrypt requires DNS-01 challenge for wildcard issuance. HTTP-01 challenge (the web server file method) cannot be used to validate a wildcard. If you want Let's Encrypt wildcard certificates, your DNS provider must support API-based record creation for the ACME DNS-01 challenge. Panelica handles this automatically for domains using Cloudflare DNS.

Multi-domain certificates (sometimes called SAN certificates or UCC certificates) include multiple distinct FQDNs in the SubjectAltName extension. Let's Encrypt supports up to 100 SANs per certificate. This is useful for hosting providers who want a single certificate covering multiple client domains, or for applications spanning multiple domains that share infrastructure.

For Sysadmins and SSL Engineers

The validation flow: how DV, OV, and EV differ behind the scenes

The operational difference between the three tiers is entirely in the validation side channel — not in the certificate format itself. All three types produce an X.509 v3 certificate with the same structure: subject, public key, validity dates, SubjectAltNames, and a CA signature.

For DV, the validation side channel is the ACME protocol (RFC 8555). The client proves domain control via one of two challenge types:

• HTTP-01: The CA requests a token at http://domain/.well-known/acme-challenge/{token}. The client places the token file. The CA fetches it and verifies the response. This challenge can be completed fully programmatically in seconds.
• DNS-01: The CA specifies a value that must appear in a TXT record at _acme-challenge.domain. The client creates the record via DNS API. The CA queries DNS and verifies. This method works behind firewalls and is required for wildcard certificates because the wildcard scope cannot be demonstrated via a single HTTP path.

For OV and EV, ACME automates the domain control portion, but the organization verification steps happen out-of-band through the CA's manual vetting process. This is why OV takes days and EV takes weeks — a human at the CA is reviewing documents, cross-referencing business registries, and in some cases making phone calls.

The resulting certificates carry different policy OIDs in the Certificate Policies extension. An EV certificate includes the EV policy OID for the issuing CA (e.g., 2.23.140.1.1 for CA/Browser Forum EV). Browsers previously used this OID to trigger the green bar display. When browsers stopped acting on the OID for UI purposes, the practical difference in certificate contents became purely informational.

ACME protocol and Panelica's HTTP-01 + DNS-01 implementations

Panelica's SSL implementation lives in backend/internal/services/ssl/. The ACME client is built on the lego library and wraps two challenge providers implemented as Go interfaces:

acme_http_provider.go handles HTTP-01 challenges. When a certificate is requested, it resolves the webroot for the domain by reading the nginx vhost configuration to find the document root, then writes the ACME challenge token file to the appropriate .well-known/acme-challenge/ path. After the CA fetches and validates the token, the file is cleaned up. This provider works for any domain whose document root Panelica manages, including domains pointing to custom directories.

acme_dns_provider.go handles DNS-01 challenges. The provider authenticates to the Cloudflare API using the account token stored in Panelica's Cloudflare integration (configurable per domain or globally), creates the _acme-challenge TXT record, waits for DNS propagation, and removes the record after validation. The two key functions in this file are SetDNS01ProviderCloudflare and UseDNS01Cloudflare. DNS-01 is required whenever a wildcard certificate is requested; Panelica automatically routes wildcard issuance through the DNS provider if a Cloudflare token is present for the domain.

Cloudflare DNS-01 provider: SetDNS01ProviderCloudflare

The DNS-01 challenge flow in Panelica operates as follows:

1. User requests a wildcard certificate (e.g., *.example.com) in the panel SSL section
2. Panel checks whether the domain has a Cloudflare integration configured with a valid API token
3. SetDNS01ProviderCloudflare initializes the lego DNS provider with the Cloudflare credentials
4. ACME client initiates the order with Let's Encrypt, receives the DNS-01 challenge token
5. UseDNS01Cloudflare creates the _acme-challenge.example.com TXT record via Cloudflare API
6. Propagation wait occurs before the CA queries DNS
7. Let's Encrypt validates, issues the certificate
8. Provider removes the TXT record
9. Certificate and private key are stored in var/ssl/ and nginx is reloaded

If the domain's DNS is not managed through Cloudflare, or if no Cloudflare token is configured, wildcard issuance is not available. Single-domain and multi-domain SAN certificates can still be issued via HTTP-01 without Cloudflare.

Cloudflare Origin Certificates: 5475-day validity and when to use them

Cloudflare Origin Certificate issuance in Panelica is handled by backend/internal/services/cloudflare/origin_cert.go. The function signature is:

IssueOriginCertificate(email, apiKey, hostnames, validityDays)

Valid validityDays values are: 7, 30, 90, 365, 730, 1095, and 5475. Panelica sets 5475 (approximately 15 years) as the default. This aligns with Cloudflare's API maximum validity for Origin Certificates.

Origin Certificates are signed by Cloudflare's own CA root, which is not trusted by public browsers. If you disable Cloudflare proxying on a domain and have only a CF Origin Certificate installed on the origin, visitors will receive a certificate error. For this reason, Panelica's Cloudflare integration tracks whether the proxy is active and will warn before issuing an Origin Certificate on a DNS-only (non-proxied) domain.

The correct configuration for full TLS with Cloudflare is: Cloudflare's SSL/TLS mode set to "Full (strict)", a publicly trusted certificate on the browser-to-edge leg (Cloudflare handles this automatically via Universal SSL), and a Cloudflare Origin Certificate on the edge-to-origin leg. This is the setup Panelica's Cloudflare deep integration targets when you enable the Cloudflare origin certificate option.

SSL renewal automation: Panelica's ssl_reconciler service

ssl_reconciler.go runs as a periodic background task and handles the full lifecycle of certificates managed by Panelica. Its responsibilities include:

• Expiry tracking: The reconciler reads stored certificate files, parses the NotAfter field, and flags certificates approaching expiry
• Pre-expiry renewal: Certificates are re-issued 30 days before expiry. The new certificate is written to the same path, and nginx is reloaded atomically
• Orphan cert backfill: Domains that exist in the panel but have no associated SSL record are detected and queued for issuance
• Duplicate cleanup: Multiple certificate records for the same domain fingerprint are deduplicated

The reconciler does not touch manually imported certificates (OV/EV certs pasted in by the operator) unless they are explicitly flagged for managed renewal. This prevents the reconciler from overwriting a purchased commercial certificate with a new Let's Encrypt DV certificate at renewal time.

Certificate lifetime trends: 397 days now, 90 days then 47 days coming

The CA/Browser Forum has progressively shortened the maximum allowed certificate validity period. The timeline:

• Pre-2015: Certificates could be valid for up to 39 months (about 3 years)
• 2015: Maximum reduced to 39 months, then to 27 months
• 2020: Apple's Safari enforced a 397-day maximum validity cap. Other browsers followed. Any certificate with NotAfter beyond 397 days from issuance was rejected.
• 2025: The 397-day cap remains the practical industry maximum
• 2026 roadmap: Let's Encrypt and other major CAs have indicated plans to move toward 90-day default lifetimes, with a further eventual goal of 47-day certificates — aligning with automated renewal as a requirement, not an option

The implication for server operators is direct: as certificate lifetimes shrink, the frequency of renewal increases, and manual renewal becomes operationally untenable. A 47-day certificate that requires manual renewal every six weeks is not a workable configuration for more than a handful of domains. Panel-level automation — specifically a reconciler that tracks expiry and re-issues certificates without operator action — becomes infrastructure-critical rather than merely convenient.

Panelica's ssl_reconciler is designed with this trajectory in mind. The renewal trigger window (currently 30 days before expiry) remains meaningful even if certificate lifetimes drop to 47 days, leaving a two-week renewal runway on each cycle.

Importing third-party OV/EV certificates into Panelica manually

When you purchase an OV or EV certificate from a commercial CA (Sectigo, DigiCert, GlobalSign, or others), the CA delivers a certificate chain file and a private key. To use this certificate with Panelica:

1. Navigate to the SSL section for the relevant domain in the panel
2. Select the manual import option
3. Paste the full certificate chain (leaf certificate followed by intermediate CAs, in PEM format)
4. Paste the private key (PEM format, unencrypted)
5. Save — Panelica writes the files to var/ssl/{domain}/ and reloads nginx with the new certificate

Manually imported certificates are not touched by the ssl_reconciler for automated renewal. You are responsible for tracking the expiry date and importing a renewed certificate before it expires. Some organizations script this using the Panelica External API (port 3002, HMAC-SHA256 authenticated) to automate the import step once their commercial CA renewal process completes.

What gets stored, signed, and presented in the TLS handshake

When a TLS connection is established with your server, the server presents its certificate chain during the handshake. The chain consists of:

• Leaf certificate: Your domain's certificate, containing the public key, SANs, validity dates, and the CA signature
• Intermediate certificate(s): One or more intermediate CA certificates bridging from the leaf to the root CA
• Root CA: Not transmitted in the handshake — the client's browser has the root CA pre-installed in its trust store

The DV/OV/EV distinction is encoded in the certificate's Subject field and Certificate Policies extension. A DV certificate's subject contains only CN=yourdomain.com. An OV certificate's subject includes O=Organization Name and C=Country. An EV certificate's subject includes all of the above plus businessCategory, serialNumber (business registration number), and jurisdictionCountry. These fields are what compliance tools and auditors inspect. Browser UI stopped surfacing them to end users in 2019, but they remain in the certificate structure itself.

What Panelica Issues, What You Buy Elsewhere

To be explicit about what Panelica's SSL stack does and does not do:

• Panelica issues: Let's Encrypt DV certificates — single domain via HTTP-01 challenge, multi-domain SAN via HTTP-01, wildcard via DNS-01 challenge with Cloudflare token
• Panelica issues: Cloudflare Origin Certificates with up to 5475-day validity — for domains proxied through Cloudflare, via the Cloudflare Origin CA API
• Panelica does not issue: OV certificates — there is no Sectigo, DigiCert, or GlobalSign reseller integration in the platform
• Panelica does not issue: EV certificates
• Panelica accepts: Any manually imported certificate and private key pair, including OV and EV certificates purchased from any commercial CA — pasted in PEM format via the panel UI

The design decision here is deliberate. The panel's SSL automation is built around the ACME protocol and Let's Encrypt because DV certificates cover the actual needs of the sites it hosts. Reselling OV and EV certificates would add commercial CA integrations, manual vetting workflows, and pricing tiers that do not correspond to any technical improvement in encryption quality. For operators who genuinely need OV or EV, the manual import path provides full compatibility.

The Certificate Comparison

Why Certificate Lifetimes Keep Shrinking (and Why Your Panel Matters More Than Ever)

In 2015, a certificate could be issued with a validity of 39 months — a bit over three years. By 2020, Apple's Safari capped acceptance at 397 days. Any certificate presented with a longer validity was rejected at the TLS handshake, not by the CA. The 397-day cap has held through 2025.

Looking ahead into 2026, Let's Encrypt and other major CAs have communicated plans to reduce default certificate lifetimes further — first toward a 90-day standard, then potentially toward 47-day certificates. The direction of the CA/Browser Forum is clear: certificates should be short-lived, and renewal should be fully automated.

The reasoning behind shorter lifetimes is straightforward. A compromised private key associated with a 39-month certificate gives an attacker a multi-year window to exploit it. A 47-day certificate limits that window significantly, and the operational cost of shorter lifetimes is zero if renewal is fully automated.

This is exactly why panel-level SSL automation matters. A hosting panel that requires you to manually log in and click a renewal button is a panel that will fail operationally as lifetimes drop. With a 47-day certificate, a missed renewal cycle means a two-week window before your site begins showing certificate errors to visitors.

Panelica's ssl_reconciler handles renewal without operator action. It checks expiry status on a schedule, initiates the ACME flow automatically when a certificate approaches the 30-day renewal window, deploys the new certificate to the correct path, and reloads nginx. When certificate lifetimes drop to 47 days, a 30-day renewal trigger still provides a two-week buffer — and the entire process happens without any intervention on your part.

Related Reading

If you found this post useful, these related articles go deeper on specific topics covered here:

• How Panelica issues 15-year Cloudflare Origin Certificates — the full implementation walkthrough
• Cloudflare DNS and SSL automation in Panelica — managing zones, mail DNS, and certificate issuance from one interface
• AutoSSL in cPanel, Plesk, and Panelica compared — how different panels handle Let's Encrypt renewal
• Free VPS control panels in 2026: an honest comparison — SSL handling as one factor among many
• Best cPanel alternatives in 2026: 8 panels compared — platform-level feature comparison including SSL automation
• Panelica vs other panels: full feature comparison