An SSL certificate error can block visitors or make a browser display a security warning. The message may identify an expired certificate, a hostname mismatch, a missing chain certificate, or the wrong server.
Similar warnings can have different causes. To troubleshoot an SSL certificate error, start with the exact hostname and warning. Then inspect the certificate, DNS path, web server, and any reverse proxy in a controlled order.
Start with the exact SSL certificate error
Record the full browser or application message before changing anything. Common examples include “certificate expired,” “certificate not valid for this name,” “certificate authority not trusted,” and “incomplete certificate chain.” Capture the complete URL and hostname.
For example, example.com, www.example.com, and portal.example.com may use different certificates or front-end systems. A certificate for one name does not automatically cover every other name.
Test the address in a private browser window and, where practical, from a second network. This helps separate a public website problem from a local clock, browser cache, antivirus inspection, or corporate proxy issue.
- Note the affected URL and port, usually HTTPS on port 443.
- Record whether every visitor sees the warning.
- Check whether HTTP redirects to HTTPS before the warning appears.
- List recent DNS, hosting, proxy, or certificate changes.
Do not bypass the warning and call the issue fixed. A bypass can hide a real identity or encryption problem. For broader context, review this DNS troubleshooting guide.
Check expiration and certificate identity
Expiration is a common cause. A certificate has “not before” and “not after” dates. The server must present a certificate that is valid at the visitor’s current time. An incorrect system clock can therefore create a warning on only one computer.
Open the certificate details in the browser and inspect both dates. Review the Subject Alternative Name field as well. It lists the hostnames covered by the certificate and provides the practical basis for hostname matching.
A wildcard certificate such as *.example.com normally covers one subdomain level, such as www.example.com. It does not normally cover the bare domain or a deeper name such as shop.eu.example.com.
If the certificate expired, renew it through the certificate authority or hosting platform. Next, confirm that the web server or proxy loads the renewed files. Renewal can succeed while production continues to present an older certificate. See what an expired certificate means for a website for related checks.
For issuance and renewal background, consult the Let’s Encrypt documentation. Exact steps depend on the authority, web server, hosting platform, and deployment method.
Investigate a hostname mismatch
A hostname mismatch means the server returned a valid certificate, but that certificate does not identify the requested name. This often follows a server move or the addition of a new subdomain.
Compare the URL with the names listed in the certificate. Check both the bare domain and the www name when visitors use both. Review staging, customer portal, mail, and API subdomains separately.
Several sites can share one IP address. The server uses the requested hostname during the TLS handshake to select a certificate. This mechanism is called Server Name Indication, or SNI.
If the listener lacks the correct site definition, it may return a default certificate for another domain. Check the HTTPS virtual-host configuration on the web server or proxy. Confirm that the certificate and private key belong together.
Never paste a private key into a public checker or send it through an unsecured channel. After a configuration change, reload the service using the platform’s documented procedure. Validate the public hostname afterward, because a local test may reach a different address.
Validate the certificate chain
Browsers build trust through a chain. The website certificate, also called the leaf certificate, links through one or more intermediate certificates to a trusted root.
Most web servers need to send the website certificate and required intermediate certificates. An incomplete chain may affect some browsers, phones, older systems, or application libraries while other clients appear to work. This SSL certificate error can therefore affect only certain users.
Review the bundle configured on the web server. Many systems expect a full-chain file rather than only the leaf certificate. Do not add a root certificate simply because a tool suggests it. Follow the certificate authority’s current instructions.
A reputable public TLS checker can reveal missing intermediates, an incorrect certificate, protocol settings, and differences between IPv4 and IPv6. Treat its output as evidence, not permission for blind changes. Related background appears in why SSL certificate problems break websites and services.
Check DNS before changing the web server
DNS connects a hostname to an address. If DNS points to the wrong host, the correct certificate on your intended server cannot help. Review the A record for IPv4 and the AAAA record for IPv6. Also check whether a CNAME points to a hosting or proxy provider.
Use the affected hostname in every test. Testing only an origin address or a different hostname can produce a certificate that visitors never receive. Cached DNS answers may also send different networks to different destinations for a while.
Compare public DNS answers from more than one resolver. A change at the registrar, DNS provider, CDN, or hosting company may have changed delegation or record values. Cloudflare’s DNS overview explains resolution, records, and nameservers.
Pay special attention to IPv6. If AAAA points to an old server, some visitors may see an old certificate while IPv4 users see the new one. Correct stale records only after verifying that the old address is no longer required.
Review reverse proxies and CDN layers
A reverse proxy receives a visitor’s request before forwarding it to the origin server. A CDN, load balancer, web application firewall, and some hosting panels can all perform this role.
This setup can create two TLS connections: browser to proxy, then proxy to origin. The certificate visible to visitors belongs to the first connection. Fixing only the origin certificate may not resolve an SSL certificate error shown publicly.
Identify every HTTPS termination point. Check the certificate and hostname settings at each layer. Confirm that the proxy serves the intended certificate and can connect securely to the origin when strict origin verification is enabled.
- The proxy still serves an older certificate after renewal.
- A new hostname exists at the origin but not at the proxy.
- The proxy sends the wrong host header to the origin.
- The origin accepts HTTP while the proxy expects HTTPS.
- IPv4 and IPv6 reach different proxy or origin settings.
Make one change at a time. Record the previous setting so you can restore service if a later test creates a new failure.
Use safe validation tools
Browser details provide a useful first check. Command-line tools can show what a server presents during a connection, but run them against the real hostname rather than only an IP address.
openssl s_client -connect example.com:443 -servername example.com -showcertsThe -servername option sends the requested hostname through SNI. Review the subject, alternative names, dates, issuer, and certificates returned by the server.
A second check uses curl:
curl -Iv https://example.com/These commands can expose redirects, connection failures, and verification results. Output varies by operating system and installed trust store. Do not disable verification merely to make a request succeed. A command result alone does not explain every SSL certificate error.
On Linux, review web-server error logs and recent deployment logs. Run a configuration test before a reload when the software supports one. Never copy a production command without confirming its syntax, paths, privileges, and service name. Mozilla’s SSL Configuration Generator can help review modern server settings.
Fix the cause, then verify externally
Apply the smallest suitable correction after identifying the cause. Renew an expired certificate, add the correct hostname, install the required intermediate chain, correct DNS, or update the proxy certificate.
Avoid changing DNS, firewall rules, and web-server settings at the same time. Multiple simultaneous changes make the result harder to explain and can extend an outage.
Afterward, test the public hostname from more than one network. Check the bare domain, www, and important subdomains. Test IPv4 and IPv6 when the domain publishes both record types.
Confirm current dates, hostname coverage, chain validation, and intended redirects. A successful TLS handshake does not prove that the website, login, API, or checkout process works.
Finally, document the certificate authority, renewal method, file locations, proxy layers, DNS owner, and alerting process. Clear records reduce the chance that a future renewal becomes an outage.
When professional help makes sense
An SSL certificate error is suitable for remote diagnosis when someone can provide the exact hostname, warning, recent change history, and access to the relevant hosting or DNS systems. Keep private keys and account credentials protected.
Tech Rescue Ops LLC can help investigate certificate deployment, DNS paths, Linux web servers, and reverse-proxy configurations when several systems are involved. Professional assistance is especially useful for customer-facing sites, multiple environments, or changes that require a careful maintenance window.