Website SSL Certificate Errors? Common HTTPS Certificate Issues and Troubleshooting

When a website suddenly shows an SSL certificate error, many people's first reaction is "Did the certificate expire?" But in practice, expiration is just one possibility. The domain not being covered, an incomplete certificate chain, or a CDN still serving an old certificate can all cause HTTPS issues. Below, we'll walk through common error messages and explain how to diagnose and resolve different SSL certificate problems.

1. First, Check What SSL Error the Browser Reports

Different SSL errors have different underlying causes. Browsers like Chrome and Edge typically display a specific error code on the security warning page. These codes are more valuable for pinpointing the issue than just seeing "Your connection is not private."

If you can identify the specific error type first, the troubleshooting scope becomes much smaller. For example, with ERR_CERT_DATE_INVALID, you'd typically check the certificate's time first. With ERR_CERT_COMMON_NAME_INVALID, focus on domain matching rather than reinstalling the same certificate repeatedly.

2. First, Check the SSL Certificate the Website Is Actually Returning

When encountering HTTPS errors, I usually don't recommend jumping straight into the server backend to reissue or reinstall the certificate. Instead, you should first confirm a more fundamental thing: Which certificate is the server actually returning to users right now? This step seems simple, but it's often the most overlooked part of SSL troubleshooting.

You may have uploaded a new certificate in the server backend, and the validity period shown there is perfectly fine. But if there's a CDN, load balancer, or reverse proxy in front of your website, users may not actually receive that certificate.

Common scenarios include:

• SSL certificate was just renewed;

• The website switched CDN providers;

• DNS records were modified;

• The website has multiple origin servers;

• CDN nodes haven't synchronized the certificate;

• Nginx configuration was changed, but the service wasn't reloaded;

• Multiple HTTPS sites are hosted on the same IP.

Use Chahu to Check the Live Certificate Status

In such cases, you can first use Chahu's SSL certificate checker to see what HTTPS certificate your website is currently returning to the public.

After entering the domain to check, pay attention to these key details:

• Is the SSL certificate still within its validity period?

• Is the domain you're accessing included in the certificate?

• Who is the issuing CA?

• Are there any issues with the certificate chain?

• Is the website actually returning the new certificate or the old one?

• Are there obvious problems with the HTTPS and TLS configuration?

This is more useful than just checking the server backend to see "certificate uploaded successfully," because the online check shows what public users actually get when they connect to your site.

Based on the results, you can quickly determine the next steps:

Separating "certificate issues" from "server configuration issues" will make the rest of your troubleshooting much easier.

3. What to Do If the SSL Certificate Has Expired

Certificate expiration is the most common and relatively easy to diagnose SSL error. SSL certificates have clear start and end times. If the current time is past the Not After date, the browser considers the certificate invalid and shows a security warning.

Common error messages include:

NET::ERR_CERT_DATE_INVALID

Or a direct message like:

Certificate Expired

The solution isn't complicated: renew or obtain a new certificate, then deploy it to your server.

The real problem often arises here:

The certificate has been renewed, but the website still shows the old one.

In this case, you can't just check the validity period in the CA panel or server dashboard. You need to confirm that the certificate actually being served online has been updated.

If your website uses Nginx, check that the certificate file paths in the configuration are correct, for example:

ssl_certificate
ssl_certificate_key

After replacing the certificate, you must reload the Nginx configuration; otherwise, the running service may still use the previously loaded files.

If you have a CDN in front, also check whether the certificate on the CDN nodes has been synchronized.

4. What to Do If the Certificate Doesn't Match the Domain

Another very common situation is when the certificate hasn't expired, but you still see:

NET::ERR_CERT_COMMON_NAME_INVALID

This error usually means:

The domain you're currently accessing is not included in the certificate's valid domain list.

For example, if the certificate covers:

example.com
www.example.com

Then accessing:

https://example.com
https://www.example.com

should work fine.

But if you access:

https://api.example.com

and api.example.com isn't listed in the certificate's SAN (Subject Alternative Name), the browser will likely show a domain mismatch error.

This issue is especially common after adding new subdomains.

Wildcard Certificates Also Have Coverage Limits

For example:

*.example.com

typically covers:

www.example.com
api.example.com
shop.example.com

But don't assume a wildcard certificate covers subdomains at any depth.

If your actual service uses:

api.shop.example.com

you need to verify that the current certificate truly covers that domain.

So when you encounter a domain mismatch, first check the SAN entries in the certificate, not just whether the certificate status says "valid."

5. Why Does the Browser Still Warn If the Certificate Hasn't Expired?

"The certificate is still valid for months, so why is the browser reporting an error?" This is not uncommon in real-world operations. Certificate validity is just one part of SSL checks; it doesn't guarantee the entire HTTPS configuration is correct.

1. Incomplete Certificate Chain

When a browser validates a website certificate, it doesn't just check the leaf certificate itself.

A complete trust chain typically looks like:

Website SSL Certificate
    ↓
Intermediate CA
    ↓
Root CA

Servers usually don't need to send the root certificate, but they should correctly provide the required intermediate certificates.

If the Intermediate Certificate is missing, you might see a strange phenomenon:

Your own computer works fine, but some mobile devices or other users report that the certificate is untrusted.

This happens because different operating systems, browsers, and devices have different local caches of intermediate certificates.

To fix this, check that your server is serving the full certificate chain, not just a single leaf certificate.

2. Using a Self-Signed Certificate

Self-signed certificates are suitable for internal networks, development, or testing environments, but public browsers don't trust them by default.

This often results in:

NET::ERR_CERT_AUTHORITY_INVALID

For public-facing websites, you should typically use a certificate issued by a CA that's trusted by mainstream browsers.

3. Incorrect Local System Time

This is a basic issue but often overlooked.

Suppose a certificate is valid from:

2026-08-01
to
2026-11-01

But your computer's local time is incorrectly set to:

2027-01-10

From the browser's perspective, that certificate has already expired.

So if only one computer shows an SSL error while other devices access the site fine, check:

• System date;

• Current time zone;

• Automatic time synchronization;

• NTP service.

If the error only occurs on a few clients, the local environment is often worth checking before the server itself.

6. Why Does the Website Still Show the Old Certificate After Updating?

One of the most frustrating situations after renewing an SSL certificate is when the backend shows the new certificate, but browsers still see the old one. This issue usually has a few possible causes.

1. Nginx or Apache Hasn't Been Reloaded

Even though the certificate files on the server have been replaced, the web server may still be running with the old configuration.

For example, after replacing:

fullchain.pem
privkey.pem

you didn't perform the corresponding reload.

For Nginx, first test the configuration, then reload:

nginx -t
nginx -s reload

If you're using a control panel or managed hosting, make sure the system actually reloaded the web service.

2. Updated the Wrong Virtual Host

A single server often hosts multiple websites.

For example:

example.com
www.example.com
api.example.com

may each have their own server block.

If you uploaded the certificate to the wrong virtual host, the current domain will continue to serve the old certificate even though the files are correct.

In this case, check together:

• Server Name;

• SNI;

• Port 443 listening configuration;

• Certificate file paths.

3. CDN Is Still Serving the Old Certificate

This is especially important if your website uses a CDN.

The actual HTTPS path is usually not:

User → Origin Server

but rather:

User
 ↓
CDN Edge Node
 ↓
Origin Server

The browser first establishes an HTTPS connection to the CDN edge node, so users see the SSL certificate returned by the CDN. Even if the origin server has been updated, as long as the CDN is still loading the old certificate, the front-end result won't change.

So after replacing a certificate, you should confirm both: whether the origin server certificate is updated, and whether the CDN edge certificate is updated.

4. Some Nodes Still Use the Old Certificate

If your website uses a global CDN, multiple nodes, or load balancing, another possibility is that different nodes have inconsistent configurations.

For example:

Shanghai node → New certificate
Hong Kong node → New certificate
Singapore node → Old certificate

In this case, you might access the site fine yourself, but overseas customers keep reporting certificate expiration. This kind of issue is hard to detect with just a local browser refresh; you need to check the actual certificate returned from different public networks or locations.

7. What to Do If HTTP Works but HTTPS Doesn't

If:

http://example.com

loads fine,

but:

https://example.com

doesn't load at all,

the problem may not be just the SSL certificate itself.

A complete HTTPS request roughly goes through:

DNS resolution
   ↓
Server or CDN
   ↓
TCP port 443 connection
   ↓
TLS handshake
   ↓
SSL certificate validation
   ↓
HTTP request
   ↓
Web application

If any of these steps fails, HTTPS can fail to connect.

First, Check Port 443

HTTP typically uses port 80, while HTTPS primarily uses port 443.

If your server's security group, firewall, or web server hasn't opened port 443, HTTPS won't work even if the SSL certificate is perfectly valid.

Check:

• Cloud server security group;

• Linux firewall;

• Nginx/Apache listening configuration;

• CDN port settings.

Check Whether the Web Server Has HTTPS Enabled

In Nginx configuration, you'll typically see something like:

listen 443 ssl;

If port 443 isn't being listened on correctly, or the SSL-related configuration isn't loaded, HTTPS connections will fail.

Check Certificate File Paths

If the certificate path is wrong, the file has been deleted, or permissions are insufficient, the web server may fail to start or reload.

So after modifying SSL configuration, it's best to test the configuration first, then reload.

Check TLS Configuration

If your server only supports outdated TLS protocols, or the cipher suites are misconfigured, newer browsers may refuse to establish a connection.

Production websites should use current, secure TLS configurations and avoid relying on legacy protocols.

8. If SSL Errors Occur After Using a CDN, Check These 4 Things

After deploying a CDN, SSL troubleshooting becomes more complex than with a single server.

Because there are at least two connections:

Visitor ↔ CDN ↔ Origin Server

If both sides use HTTPS, you actually have:

Visitor
 ↓ HTTPS
CDN
 ↓ HTTPS
Origin Server

So, the front-end HTTPS being fine doesn't mean the CDN-to-origin HTTPS is also fine.

1. Is the Correct Certificate Bound to the CDN?

Many people think that once they update the certificate on the origin server, the whole website is updated.

But for CDN websites, the edge HTTPS often has its own separate certificate configuration.

You should verify:

• Is the certificate bound to the CDN correct?

• Does the certificate cover the correct domain?

• Is the certificate still within its validity period?

• Have new subdomains been added to the certificate?

2. Have the CDN Nodes Synchronized?

After changing certificates or adding new domains, different edge nodes may have temporary configuration inconsistencies.

If some regions work fine while others report certificate errors, focus on node synchronization.

3. Is CDN-to-Origin HTTPS Working?

Sometimes the user-to-CDN segment is fine, but the CDN fails to establish a TLS connection to the origin server.

For example:

User → HTTPS → CDN
              ↓
            HTTPS
              ↓
           Origin Server

If the origin certificate has expired, domain validation fails, or TLS configuration is wrong, the CDN may not be able to fetch from the origin.

The final symptom might not be a browser certificate warning, but rather:

502
525
526
SSL Handshake Failed

Error codes vary by provider, but the troubleshooting logic is similar.

4. Check SNI Configuration

When multiple HTTPS sites are hosted on the same IP, the server typically relies on SNI to determine which certificate to return.

If SNI is misconfigured, you might see:

Accessing example.com

but the server returns:

a certificate for otherdomain.com

The browser will naturally consider the certificate mismatched.

This issue often occurs in:

• Multi-site servers;

• Reverse proxies;

• CDN origin pulls;

• Load balancers.

9. A Step-by-Step Troubleshooting Order for SSL Certificate Errors

If you're not sure where the problem lies, follow this order to check layer by layer:

Browser shows HTTPS / SSL error
        ↓
Check the specific error code
        ↓
Use Chahu to check the SSL certificate actually returned to the public
        ↓
Is the certificate expired?
   ├─ Yes → Renew and redeploy the certificate
   └─ No
        ↓
Is the current domain covered by the certificate?
   ├─ No → Issue a new certificate with the correct domain
   └─ Yes
        ↓
Is the certificate chain complete?
   ├─ No → Add the Intermediate CA
   └─ Yes
        ↓
Check port 443 and TLS configuration
        ↓
Check Nginx / Apache configuration
        ↓
Does the website use a CDN?
   ├─ Yes → Check CDN certificate, node sync, SNI, and origin HTTPS
   └─ No → Continue checking origin HTTPS configuration
        ↓
Re-test the website's HTTPS status

This approach is more effective than immediately reissuing a certificate after seeing an error, because many HTTPS issues aren't actually related to certificate issuance itself. Especially for sites that have just switched CDNs, renewed certificates, or migrated servers, confirming what the public actually receives first can save a lot of unnecessary troubleshooting time.

Conclusion

An SSL certificate error may look like just a security warning in the browser, but when you dig into it, the problem could be in the certificate, domain, certificate chain, server, TLS, CDN, or client. Certificate expiration is actually one of the simpler cases. In real-world operations, the more time-consuming issues are often when the certificate has been updated but the live site still serves the old one, the SAN doesn't cover a newly added domain, the certificate chain is incomplete, or the HTTPS configuration between the origin and CDN isn't synchronized.

So when you encounter an SSL certificate error, don't rush to reissue the certificate. First, confirm what certificate the website is actually returning, then troubleshoot step by step in this order: Validity → Domain Match → Certificate Chain → Port 443 → TLS → Web Server → CDN. This will usually help you find the real problem more efficiently.

Related Q&A

1. Can a personal blog and an e-commerce website use the same type of SSL certificate?

Not at all. Free certificates are typically DV-level, which only verify that you control the domain. They're suitable for personal blogs, test projects, and other scenarios with low identity verification requirements. But for e-commerce, payment, government, or other businesses involving financial transactions or sensitive information, users need to confirm that the website is backed by a real, trusted organization. In those cases, you must use OV or EV-level paid certificates. In terms of encryption strength, free and paid certificates are the same, but paid certificates offer additional benefits like organization identity verification, technical support, and insurance coverage.

2. Should I choose a wildcard certificate or a multi-domain certificate?

It depends on your domain structure. A wildcard certificate, like *.example.com, covers all first-level subdomains under the same primary domain, such as www.example.com, api.example.com, and shop.example.com. Adding new subdomains doesn't require extra steps. A multi-domain certificate (SAN certificate) is for different primary domains, such as protecting example.com, example.net, and example.org simultaneously. If your subdomains are deeply nested, like api.shop.example.com, a wildcard certificate won't cover them, and you'll need to handle that separately.

3. Why does my computer access the site fine, but my phone browser says the certificate is untrusted?

This is most likely a certificate chain issue. Different operating systems and browsers have different built-in root certificate stores. Older Android versions may lack root certificates for certain CAs. If your server only returns the leaf certificate without the intermediate certificate, your computer might work because it has the intermediate cached locally, but your phone might not have it and thus reports an error. The solution is to deploy the full certificate chain on your server, combining the intermediate and leaf certificates.

4. Can an incorrect local computer time really cause SSL certificate errors when browsing?

Yes, it can, and it's quite common (the error is usually NET::ERR_CERT_DATE_INVALID). HTTPS certificate validation is based on timestamps (with a "not before" and "not after" time). If your computer or phone's system time is significantly off (for example, the CMOS battery died and the time reset to years ago, or it's set to the future), the browser will compare the local time against the certificate's validity period and mistakenly conclude that the certificate is "not yet valid" or "has expired." We recommend enabling the system's NTP automatic time synchronization.