An SSL certificate begins as an application for trust. A website owner can request a certificate for a domain, but the Certificate Authority cannot simply take that request at face value. Before issuing a publicly trusted certificate, the CA has to verify that the applicant has control over the requested identity and, for certain validation levels, establish additional information about the organization behind it.
That verification happens before the certificate reaches the server. After issuance, another set of checks takes place when browsers and other TLS clients evaluate the certificate during a connection. The two stages are related but different: the CA validates the applicant before issuance, while the browser validates the resulting certificate and its trust path during the TLS connection.
The distinction is becoming more important in 2026. Publicly trusted Subscriber Certificates issued from March 15, 2026 through March 14, 2027 can have a maximum validity period of 200 days. That maximum falls to 100 days in 2027 and 47 days in 2029. The permitted reuse period for domain and IP validation data is also being reduced, making certificate validation increasingly connected to automated renewal and certificate management.
What is SSL Certificate Validation?
SSL certificate validation is the process a Certificate Authority uses to verify the identity information associated with a certificate request before issuing a publicly trusted TLS certificate.
For a Domain Validation certificate, the main requirement is evidence that the applicant controls the requested domain or IP address. Organization Validation adds verification of information about the organization, while Extended Validation requires a more extensive set of organization and authorization checks.
The Certificate Authority is therefore responsible for establishing the evidence behind the certificate identity. It is not simply confirming that a website is online or that the applicant has paid for a certificate.
The current CA/Browser Forum Baseline Requirements define requirements that publicly trusted CAs must follow when validating and issuing TLS certificates.
It is also important to separate validation from encryption. DV, OV and EV describe the level of identity verification performed before issuance. They do not represent different levels of TLS encryption.
Why Do SSL Certificates Need Validation?
The reason for validation is straightforward: a trusted certificate should not be issued to someone who has no legitimate control over the identity represented by it.
If an attacker could request a certificate for a domain without demonstrating control over that domain, the certificate could potentially be used to impersonate the legitimate website. A browser could see a certificate signed by a trusted CA without knowing that the person who obtained it was unauthorized.
Validation provides the evidence that connects the applicant with the requested identity.
For a DV certificate, the evidence usually comes from control of domain infrastructure. For OV and EV, the CA performs additional checks concerning the organization and the person requesting the certificate.
A certificate therefore establishes trust in an identity under the applicable validation rules. It does not prove that the website itself is secure, that its application contains no vulnerabilities, or that the organization behind it can never be compromised.
SSL Certificate Validation Process: From Request to Issuance
The complete process can be viewed as a sequence:
Certificate request → identity validation → CA verification → certificate issuance → deployment → browser verification → renewal or revocation
The details vary depending on the CA, certificate and validation method, but the underlying workflow remains similar.
Automated certificate issuance commonly uses ACME. The ACME protocol defines mechanisms for certificate orders, identifier authorization, validation challenges, issuance and revocation.
Step 1: Generate a Certificate Request
The process starts when a website owner, administrator or certificate-management system requests a certificate for one or more identities.
The applicant generates a public/private key pair and, in a traditional workflow, creates a Certificate Signing Request containing the public-key information and requested certificate details. The private key remains under the applicant’s control.
The identities included in the request determine what the CA needs to validate. A certificate for www.example.com creates a different request from one containing several SAN entries or a wildcard identity.
This is why the certificate request is more than an administrative form. It defines the identities that the CA is being asked to certify and establishes the starting point for the validation process.
Step 2: Determine the Required Validation
The CA determines which verification requirements apply to the request.
For DV, the central requirement is proving control over the requested domain or IP address. OV requires that control plus organization verification. EV adds further checks concerning organizational identity and authorization.
These validation levels should not be confused with certificate coverage.
Validation describes how identity is verified.
Coverage describes which identities the certificate can represent.
A Wildcard certificate can therefore be DV, OV or another applicable validation level. A SAN certificate can also be issued under different validation levels.
This distinction is important because a certificate’s coverage does not remove the requirement to validate the identities contained within the request.
How Domain Validation Works
Domain Validation is the most common form of validation for publicly trusted certificates.
The CA needs evidence that the applicant controls the domain or IP address included in the certificate request. Rather than accepting a statement from the applicant, the CA provides or expects a challenge that requires access to infrastructure associated with that identity.
Common automated methods include:
- DNS-01, which uses a DNS TXT record
- HTTP-01, which uses a response served through the domain’s web infrastructure
- TLS-ALPN-01, which performs validation at the TLS layer for appropriate environments
The ACME specification defines the DNS-01 and HTTP-01 challenge mechanisms used in automated certificate issuance.
The important thing is not which method is used. The objective is the same: the applicant must demonstrate effective control of the identity for which the certificate is being requested.
DNS-01 Validation
DNS-01 uses the domain’s DNS infrastructure to prove control.
The certificate-management system receives a challenge value and publishes the required information in a DNS TXT record. The CA queries the relevant DNS location and checks whether the expected value is available.
DNS validation is particularly useful when the website’s HTTP infrastructure is not convenient for validation. An application can sit behind a CDN, reverse proxy or private infrastructure while domain control is established through DNS.
It is also useful for wildcard certificates because validation can take place at the domain level rather than requiring an HTTP challenge for each subdomain.
The approach does, however, make DNS security part of certificate security. DNS API credentials and access to the relevant zones should be tightly controlled because unauthorized DNS changes can affect certificate validation.
HTTP-01 Validation
HTTP-01 uses the website’s HTTP infrastructure to demonstrate control of the requested domain.
The applicant places a CA-provided challenge response at the expected location, and the CA retrieves that response through the domain.
For a simple website, the process can be straightforward. Problems become more common when requests pass through several infrastructure layers, such as CDNs, WAFs, reverse proxies and load balancers.
A challenge can fail even when the applicant controls the domain if the request reaches the wrong origin, the challenge file is inaccessible, or a routing rule changes the response.
The HTTP-01 challenge is defined within the ACME protocol and provides a standardized way to demonstrate control through web infrastructure.
TLS-ALPN-01 Validation
TLS-ALPN-01 performs validation at the TLS layer and is mainly useful for operators controlling the TLS termination point.
It can be appropriate for specialized reverse-proxy and hosting architectures where HTTP-based validation is inconvenient. For ordinary websites, DNS-01 and HTTP-01 are generally more familiar approaches.
The important distinction is that the validation mechanism changes, but the purpose does not. The CA still needs evidence that the applicant controls the requested identifier.
How Organization Validation Works
Domain control alone is not sufficient for an OV certificate.
The CA also needs to establish information about the organization associated with the certificate. Depending on the applicable requirements, this can involve verifying the organization’s legal identity, address, telephone information and the authority of the requester.
That additional work is what separates organization validation from a basic automated domain-control check.
The process can take longer because the CA has to verify information that cannot be established simply by placing a DNS record or HTTP file on a domain.
Organizations that specifically require organization-level identity assurance can then evaluate OV SSL providers based on validation requirements, coverage, support and certificate-management capabilities.
How Extended Validation Works
Extended Validation involves a more extensive organization-verification process than DV and OV.
The CA has to establish additional information about the organization and verify the authority associated with the certificate request. The purpose is to provide greater assurance about the identity represented by the certificate.
EV should not be interpreted as a stronger form of encryption. The additional assurance comes from the validation process that takes place before issuance.
Organizations considering EV SSL certificates should therefore evaluate whether the additional identity assurance serves a genuine business, contractual or trust requirement.
What Does the CA Actually Verify?
The exact checks depend on the certificate and validation method, but the process can involve several categories of information.
- Domain or IP control: Evidence that the applicant controls the requested identity.
- Organization identity: Information used for OV and EV verification.
- Requester authorization: Evidence that the person requesting the certificate is authorized where applicable.
- Certificate identities: The names included in the certificate must satisfy the applicable issuance requirements.
- CAA policy: The CA may need to determine whether DNS policy permits it to issue the certificate.
These checks work together. Passing one does not automatically mean every other requirement has been satisfied.
How SAN Certificates Fit Into Validation
A SAN certificate contains multiple explicitly listed identities.
A certificate could contain:
example.com
www.example.com
api.example.com
portal.example.com
The important point is that adding several names does not turn them into one automatically validated identity. The requested identities still have to meet the applicable requirements.
The browser later uses the certificate’s SAN information when determining whether the certificate covers the hostname being accessed. The Subject Alternative Name field is therefore important both to certificate issuance and subsequent hostname verification.
For organizations that know they need several explicitly named domains or hostnames, Multi-Domain SAN certificates can provide a practical coverage model.
How Wildcard Certificates Fit Into Validation
Wildcard certificates use a different coverage model from SAN certificates.
A certificate containing:
*.example.com
can cover first-level subdomains such as:
www.example.com
api.example.com
and:
shop.example.com
It does not automatically cover the root domain example.com, nor does it automatically cover deeper names such as admin.shop.example.com.
Wildcard is therefore a question of certificate coverage rather than validation level.
DNS-based validation can be particularly useful for wildcard issuance because control can be demonstrated through the domain’s DNS infrastructure. The relationship between the two coverage approaches is explained in the comparison of Wildcard and SAN certificates.
Where CAA Fits Into Certificate Validation
Certificate Authority Authorization, or CAA, provides a DNS-based policy mechanism that allows domain owners to specify which Certificate Authorities are authorized to issue certificates for their domains.
CAA does not replace domain validation. An applicant still has to prove control of the requested domain.
Instead, CAA adds another condition around issuance. An applicant could successfully demonstrate domain control but still encounter an issuance problem if the selected CA is not authorized by the domain’s CAA policy.
The CA/Browser Forum Baseline Requirements include rules governing CAA processing during publicly trusted certificate issuance.
For organizations managing multiple domains, CAA can therefore become part of the certificate governance process.
What Happens After SSL Validation Succeeds?
Once the CA has completed the required checks and the request satisfies the other issuance requirements, the certificate can be issued.
The certificate contains the relevant identity information, public key, issuer information, validity period and applicable extensions. The CA signs the certificate, allowing the server to present it during a TLS connection.
The work does not end there.
The certificate must be installed with the corresponding private key, and the server may also need to provide the appropriate intermediate certificates. A certificate can be legitimately issued and still cause a browser error if the deployment is incorrect.
This is where certificate issuance and certificate deployment become separate concerns.
How Browsers Verify an SSL Certificate
The browser performs its own verification after receiving the certificate from the server.
It can evaluate:
- Whether the certificate is within its validity period
- Whether the requested hostname matches
- Whether the certificate signature is valid
- Whether a trusted certificate chain can be constructed
- Whether applicable certificate-status information indicates that the certificate remains acceptable
The certificate chain of trust is particularly important here. The browser needs to establish a path from the server certificate through the appropriate intermediate CA to a trusted root.
A certificate can therefore pass the CA’s original validation process and still produce a browser warning after deployment if the hostname is wrong, the certificate chain is incomplete or the certificate has expired.
Common SSL Certificate Validation Failures
Validation failures usually happen because the CA cannot obtain the evidence it expects.
For DNS validation, common causes include:
- Incorrect TXT record
- Record published in the wrong DNS zone
- DNS propagation problems
- Insufficient DNS permissions
- Automation credentials that cannot modify the required record
HTTP validation has a different set of failure points:
- Challenge file unavailable
- Incorrect routing
- CDN or proxy interference
- WAF restrictions
- Challenge reaching the wrong origin server
- Unexpected redirects
Organization validation can fail when company information cannot be independently verified or when the requester cannot satisfy the required authorization checks.
CAA can also prevent issuance when the selected CA is not authorized to issue for the domain.
The right troubleshooting approach is therefore to identify which validation stage failed instead of treating every certificate problem as the same SSL error.
Can a Validated Certificate Still Fail in a Browser?
Yes.
CA validation happens before issuance. Browser validation happens when the certificate is presented during a TLS connection.
A certificate can therefore be legitimate and correctly signed while still failing client-side checks.
A common example is hostname mismatch. A certificate issued for www.example.com does not automatically cover api.example.com. The certificate may be unexpired and trusted by the browser, but the identity does not match the hostname being requested.
This is the situation behind many SSL hostname mismatch errors.
An incomplete certificate chain is another example. The CA may have issued the certificate correctly, but the server can still be configured incorrectly and fail to provide the intermediate certificate required by the client.
What Happens After a Certificate Is Issued?
Certificate validation is only one stage in the certificate lifecycle.
Once a certificate is deployed, organizations need to track where it is installed, who owns it, when it expires, how it will be renewed and what should happen if it needs to be revoked.
A certificate can become a problem even when its original validation was completely correct. It can expire, be installed on the wrong server, have an exposed private key or remain deployed after the underlying application has changed.
This is why certificate lifecycle management becomes increasingly important as certificate inventories grow.
For organizations managing many certificates, expiration monitoring is particularly important because a missed renewal can create an outage even though there is nothing wrong with the certificate’s original validation.
Certificate Revocation and Status Checking
Revocation deals with certificates that should no longer be trusted before their scheduled expiration.
A certificate may need to be revoked after private-key compromise, incorrect issuance or another event that makes continued trust inappropriate.
Certificate Revocation Lists and OCSP provide different mechanisms for communicating certificate status. The practical differences between CRL and OCSP become relevant when designing certificate-status and revocation processes.
OCSP stapling provides another approach in which status information can be delivered as part of the TLS connection rather than requiring every client to make a separate OCSP request.
These mechanisms belong to the post-issuance side of certificate trust, rather than the initial domain-validation stage.
Certificate Transparency Adds Visibility After Issuance
Certificate Transparency provides another layer of visibility once a publicly trusted certificate has been issued.
Certificates from publicly trusted CAs can appear in Certificate Transparency logs, allowing domain owners and security teams to identify certificates issued for their domains.
This can reveal certificates that were not present in an organization’s internal inventory, including certificates associated with forgotten applications, legacy infrastructure or unexpected issuance.
For larger organizations, Certificate Transparency monitoring can therefore complement internal certificate discovery and lifecycle-management processes.
Why SSL Certificate Validation Is Changing in 2026
Certificate validation is becoming more operationally significant because certificate lifetimes are getting shorter.
For publicly trusted Subscriber Certificates issued from March 15, 2026 through March 14, 2027, the maximum validity period is 200 days. The maximum falls to 100 days from March 15, 2027 and 47 days from March 15, 2029.
The validation-data schedule is separate. Domain and IP validation data can be reused for up to 200 days during the first period, 100 days beginning in 2027 and only 10 days beginning in 2029.
The distinction matters because shorter certificates and shorter validation-data reuse periods create two different operational changes. Organizations need to replace certificates more frequently, and they will also have less time to rely on previously completed domain or IP validation.
The CA/Browser Forum Baseline Requirements provide the applicable timetable.
What 47-Day Certificates Mean for Validation
A 47-day certificate lifetime changes certificate management from an occasional administrative exercise into a much more continuous process.
An organization managing several hundred certificates could have certificates reaching renewal at different times across websites, APIs, CDNs, cloud load balancers and other TLS termination points. Repeating the validation and deployment process manually would create unnecessary operational risk.
The move toward 47-day SSL certificates therefore makes automation increasingly important.
ACME can automate much of the process, but automation does not remove the validation requirement. It allows the system to repeatedly obtain the evidence required by the CA, request replacement certificates and move them through deployment without requiring an administrator to perform every step manually.
How ACME Automates Certificate Validation
ACME connects certificate requests with automated validation and issuance.
An ACME client can communicate with the CA, request authorization for a domain, complete the required challenge and request the certificate once the authorization succeeds.
The protocol also supports certificate revocation, making it useful across more of the certificate lifecycle than simply initial issuance.
The ACME protocol is particularly relevant as certificate lifetimes shorten because the number of manual renewal operations would otherwise grow rapidly.
Automation does not make the CA trust the applicant without evidence. It simply makes the evidence-gathering and certificate-management workflow repeatable.
What Can Break Automated Validation?
Automated validation depends on the infrastructure around it.
DNS validation depends on access to the correct DNS zone and reliable automation credentials. HTTP validation depends on the challenge reaching the correct web infrastructure. CAA configuration can restrict the CA that is allowed to issue, while CDN and proxy changes can interfere with HTTP challenges.
Common operational dependencies include:
- DNS API permissions
- DNS record management
- CDN configuration
- Reverse-proxy routing
- WAF policies
- Firewall rules
- Load-balancer configuration
- Certificate-management credentials
This is why certificate automation should be treated as part of the security architecture rather than as a separate convenience tool.
SSL Certificate Validation Checklist
Before requesting a certificate, verify the following:
- Certificate identities: Confirm every domain or IP address that actually needs protection.
- Validation level: Decide whether DV, OV or EV meets the identity-assurance requirement.
- Validation method: Select DNS, HTTP or another supported method based on the infrastructure.
- DNS access: Confirm that the certificate-management system can create the required validation records.
- HTTP access: Make sure the challenge can reach the correct server if HTTP validation is used.
- CAA policy: Check whether the selected CA is authorized to issue for the domain.
- SAN coverage: Confirm every hostname that needs to appear in a multi-domain certificate.
- Wildcard scope: Make sure wildcard coverage actually matches the subdomain structure.
- Private-key management: Determine where keys will be generated and stored.
- Certificate chain: Prepare the required intermediate certificates for deployment.
- Renewal automation: Establish how certificates will be renewed before expiration.
- Monitoring: Track certificates across all servers, applications and infrastructure.
- Revocation: Maintain a process for removing certificates that should no longer be trusted.
For larger certificate inventories, these individual tasks become part of a broader certificate lifecycle rather than separate manual activities.
Final Takeaway
SSL certificate validation is the process that establishes whether an applicant is entitled to receive a trusted certificate for a particular identity. The process starts with the certificate request, continues through domain or IP validation and, where required, organization verification, and ends with certificate issuance.
DNS-01, HTTP-01 and TLS-ALPN-01 provide different ways to demonstrate control. OV and EV introduce additional organization checks. SAN and Wildcard certificates affect the identities represented by the certificate but do not replace the underlying validation requirements.
After issuance, the certificate enters another stage of trust verification. The server has to present it correctly, the browser has to validate the hostname and trust chain, and the organization has to monitor expiration, revocation and unexpected issuance.
That final part is becoming more important in 2026. Public certificate lifetimes are moving toward 100 days and eventually 47 days, while the permitted reuse of domain and IP validation data is also becoming shorter.
The practical consequence is straightforward: SSL certificate validation is becoming a continuous operational process rather than a one-time certificate-ordering task. Organizations that combine reliable domain validation with automated issuance, deployment, monitoring and renewal will be better prepared for the shorter certificate lifetimes ahead.
Frequently Asked Questions
How does a CA verify domain ownership?
A CA requires evidence that the applicant controls the requested domain or IP address. Depending on the validation method, that evidence can come from a DNS record, an HTTP challenge or another approved mechanism.
What is DNS-01 validation?
DNS-01 requires the applicant to publish a specific validation value in DNS. The CA retrieves the record and uses it as evidence that the applicant controls the domain.
What is HTTP-01 validation?
HTTP-01 requires the applicant to serve a specific challenge response through the requested domain. The CA retrieves the response and checks it against the expected value.
Is DNS validation better than HTTP validation?
Neither method is universally better. DNS validation is particularly useful for wildcard certificates and infrastructure where HTTP validation is difficult. HTTP validation can be convenient for conventional websites with straightforward server access.
Does DV verify the organization behind a website?
No. DV primarily establishes control of the domain or IP address. It does not provide the organization verification associated with OV or EV.
Does OV provide stronger encryption than DV?
No. OV provides additional organization verification. TLS encryption does not become inherently stronger because the certificate uses OV validation.
Does EV provide stronger encryption?
No. EV provides more extensive identity verification. It does not represent a stronger encryption algorithm.
Can a Wildcard certificate be DV?
Yes. Wildcard describes the certificate’s coverage rather than its validation level.
Does a Wildcard certificate cover the root domain?
No. A certificate for *.example.com does not automatically cover example.com.
Can a certificate pass CA validation and still produce a browser error?
Yes. The browser performs its own checks after receiving the certificate. Hostname mismatch, incomplete chains, expiration and certificate-status issues can cause problems even when the CA issued the certificate correctly.
What happens when SSL certificate validation fails?
The CA does not issue the certificate until the required validation succeeds. The cause may be a DNS or HTTP challenge problem, CAA restriction, organization-verification issue or another configuration error.
Why are SSL certificates becoming shorter-lived?
The CA/Browser Forum has adopted a schedule that reduces the maximum validity period of publicly trusted Subscriber Certificates from 200 days in 2026 to 100 days in 2027 and 47 days in 2029.
Will certificate validation need to happen more often?
Yes, particularly as the permitted reuse period for domain and IP validation data decreases. Under the current schedule, that reuse period eventually falls to 10 days in 2029.
Why is automated validation becoming important?
Shorter certificate lifetimes mean organizations have to repeat certificate issuance and renewal activities more frequently. Automation allows validation, issuance and deployment to be repeated without relying on manual intervention for every certificate.
