Domain Validation (DV) certificates are the most basic type of TLS certificate, requiring only proof that the applicant controls the domain in question. The validation process is entirely automated: the Certificate Authority issues a challenge — either placing a specific TXT record in the domain's DNS zone, hosting a verification file at a known HTTP path, or verifying via email to a domain contact — and once the challenge is satisfied, the certificate is issued within minutes. Let's Encrypt is the dominant provider of DV certificates, issuing them free of charge through the ACME protocol and providing a fully automated renewal workflow.
DV certificates provide encryption for the connection between the browser and the server. They do not provide any assurance about the identity of the organization behind the website. A phishing site using a domain name designed to impersonate a legitimate bank can obtain a DV certificate in minutes, displaying a padlock in the browser's address bar. This is why the padlock icon alone is not a reliable trust indicator for the legitimacy of a site — it only indicates that the connection is encrypted. DV certificates are appropriate for personal websites, development environments, blogs, and internal infrastructure where organizational identity assurance is not a requirement.
- Validation method: DNS TXT record challenge, HTTP file challenge, or email — all automated
- Issuance time: typically minutes for fully automated certificate authority systems
- Identity assurance: domain control only — no organizational identity is verified or included
- Cost: free from Let's Encrypt; low commercial cost from other CAs
- Best suited for: personal sites, blogs, development infrastructure, and internal tooling
Organization Validation (OV) certificates require manual vetting of the organization's identity by the Certificate Authority in addition to domain control verification. The CA verifies that the organization named in the certificate actually exists as a legal entity, typically by cross-referencing government business registration databases, Dun and Bradstreet records, or by calling the organization at a phone number obtained from an independent, third-party source. This manual process takes days rather than minutes. The organization's verified name, country, and locality appear in the certificate's subject fields, visible to any user or security tool that inspects the certificate details.
OV certificates provide a meaningful step up in identity assurance compared to DV certificates. When a security-conscious user or an automated scanning tool inspects the certificate of a business website and sees the organization's verified legal name in the subject field, it provides confirmation that the certificate was issued to a real, identifiable organization rather than an anonymous domain registrant. OV certificates are appropriate for business websites, e-commerce storefronts, and customer-facing applications where establishing organizational identity adds tangible value to the trust relationship with users and auditors.
- Validation method: domain control verification plus manual organizational identity vetting
- Issuance time: typically 1 to 5 business days depending on the CA and documentation availability
- Identity assurance: legal organization name verified and present in the certificate subject field
- Cost: significantly higher than DV; pricing varies between commercial certificate authorities
- Best suited for: business websites, e-commerce platforms, and customer-facing portals
Extended Validation (EV) certificates represent the highest level of identity assurance available from public Certificate Authorities. The validation process follows strict guidelines established by the CA/Browser Forum and requires verification of legal existence, physical address, operational existence, exclusive right to use the domain, and formal authorization of the certificate request by company officers. CAs must follow a standardized multi-step verification process, historically taking one to two weeks to complete. The rigor of EV validation significantly exceeds that of OV validation.
Major browsers removed the prominent green address bar that previously indicated an EV certificate in 2019, with Chrome leading the change followed by Firefox and Safari. Research showed that users did not reliably distinguish EV indicators from standard padlocks, and that threat actors obtained EV certificates for deceptively named companies to display the green bar on phishing sites. EV certificates today do not produce any visible difference in the browser address bar from OV or DV certificates for ordinary users. However, the verified organization details remain in the certificate subject and are still valued in regulated industries and enterprise environments where certificate inspection is part of compliance verification workflows.
- Validation method: comprehensive multi-step vetting per CA/Browser Forum EV Guidelines
- Issuance time: typically 1 to 2 weeks due to extensive manual identity verification requirements
- Identity assurance: highest available — legal, physical, and operational existence all independently verified
- Browser UI: green address bar removed in 2019 by all major browsers — no visible difference from DV or OV
- Still useful for: regulated industries, enterprise environments, and compliance-driven certificate inspection
Every TLS certificate is part of a chain that connects it to a root Certificate Authority that browsers trust by default. At the top of the chain is the root CA certificate, which is self-signed and pre-installed in the operating system's or browser's trust store. Root CAs do not issue end-entity certificates directly; instead, they sign intermediate CA certificates. Intermediate CAs then sign the end-entity leaf certificates that are installed on web servers. This two-level structure means root CA private keys can be kept offline in hardware security modules, reducing the catastrophic risk of compromise to the root.
When a browser connects to a TLS-protected website, the server presents its leaf certificate along with the chain of intermediate CA certificates. The browser works up the chain, verifying each cryptographic signature, until it reaches a certificate signed by a trusted root CA in its trust store. If any signature in the chain is invalid, or if the chain cannot be connected to a trusted root, the browser displays a certificate error and warns the user. Proper server configuration requires including all intermediate certificates in the chain presented to clients — omitting intermediates is a common misconfiguration that causes intermittent certificate errors for users whose browsers have not previously cached the intermediate.
- Root CA: self-signed, pre-installed in OS and browser trust stores, private key kept offline in HSMs
- Intermediate CA: signed by root, used for daily certificate issuance operations
- Leaf certificate: your server's certificate, signed by an intermediate CA
- Always include the full certificate chain on your server — omitting intermediates causes browser errors
- Verify your chain with
openssl s_client -connect example.com:443 -showcerts
Modern browsers perform several layered checks when validating a TLS certificate during the handshake process. First, the browser builds the certificate chain from the leaf certificate to a trusted root and verifies each cryptographic signature in the chain. Second, it checks that the certificate's Subject Alternative Names (SANs) include the hostname being connected to — wildcard certificates matching *.example.com are valid for one subdomain level. Third, it verifies that the current date falls within the certificate's validity period between the NotBefore and NotAfter dates. Fourth, it checks certificate revocation status through Online Certificate Status Protocol (OCSP) stapling or Certificate Revocation Lists (CRLs).
Certificate Transparency enforcement is an additional check enforced by Chrome since April 2018. Every certificate trusted by Chrome must have at least two Signed Certificate Timestamps from independent CT logs embedded in the certificate, delivered via TLS extension, or provided through OCSP stapling. Certificates issued without valid SCTs are rejected by Chrome regardless of whether all other validation checks pass. This requirement ensures that all publicly trusted certificates are logged in auditable public logs, making unauthorized certificate issuance detectable within hours of issuance.
- Chain validation: every signature in the chain from leaf to root must be cryptographically valid
- Hostname match: the certificate SANs must include the exact hostname or a matching wildcard
- Validity period: current date must fall between the certificate's NotBefore and NotAfter timestamps
- Revocation check: OCSP or CRL confirms the certificate has not been revoked by the issuing CA
- Certificate Transparency: at least two SCTs from independent logs required for Chrome acceptance
Let's Encrypt revolutionized TLS certificate management by providing free DV certificates issued and renewed through the ACME protocol (Automatic Certificate Management Environment, RFC 8555). Let's Encrypt certificates have a 90-day validity period by deliberate design — the short lifetime limits exposure from a compromised private key and forces automation, eliminating the common scenario of forgotten certificate renewals that cause unexpected production outages when certificates expire. The 90-day period also encourages organizations to implement the automation infrastructure they need for reliable certificate lifecycle management.
The certbot tool, maintained by the Electronic Frontier Foundation, is the most widely used ACME client for automating Let's Encrypt certificate issuance and renewal. Running certbot --nginx -d example.com obtains a certificate, automatically modifies the Nginx configuration to use it, and installs a systemd timer or cron job for automatic renewal. The ACME DNS-01 challenge type enables issuance of wildcard certificates covering all subdomains, requiring the ACME client to create a DNS TXT record to prove domain ownership. Most major DNS providers offer API access that ACME clients can use to automate DNS-01 challenges without manual administrator intervention.
- Let's Encrypt issues free DV certificates with 90-day validity — the short period encourages automation
- ACME protocol (RFC 8555) automates certificate issuance, renewal, and revocation
certbot --nginx -d example.com— obtain and configure a certificate for Nginx automatically- DNS-01 challenge: required for wildcard certificates; creates a TXT record in DNS to prove ownership
- Configure automated renewal to run at 60 days to provide a 30-day buffer before expiry