What Happens When an SSL Certificate Is Misconfigured? Common Errors Explained

Installing an SSL certificate is only one part of securing a website with HTTPS. The certificate also has to be issued for the correct domain, installed on the correct server, paired with the right private key, served with the required certificate chain, and configured correctly across web servers, CDNs, load balancers, and reverse proxies.

When any part of that setup is wrong, visitors may see browser security warnings, broken pages, failed API requests, redirect loops, or complete connection failures. In some cases, the website works normally in one browser but fails in another, making the problem even harder to identify.

A misconfigured SSL certificate does not always mean the certificate itself is bad. The certificate may be perfectly valid while the surrounding TLS configuration is incorrect. Understanding the difference is important because replacing a certificate will not fix a server configuration problem.

What Does an SSL Certificate Misconfiguration Mean?

An SSL certificate misconfiguration occurs when a website's HTTPS environment does not correctly present, validate, or use the certificate required for the requested hostname.

The problem can happen during certificate installation, server configuration, renewal, DNS changes, CDN setup, or migration to a new hosting environment. It can also appear after a certificate is renewed if the new certificate is installed on the origin server but an older certificate remains active on a load balancer or CDN.

Common examples include:

• The certificate has expired.
  
• The certificate does not cover the requested hostname.
  
• The wrong certificate is installed.
  
• An intermediate certificate is missing.
  
• The private key does not match the certificate.
  
• HTTPS is configured on one server but not another.
  
• The CDN and origin server use incompatible configurations.
  
• HTTP and HTTPS redirects create a loop.
  
• A website contains HTTP resources after moving to HTTPS.
  
• The server supports outdated or incompatible TLS settings.

These problems can produce very different symptoms, so the first step should always be identifying the actual error rather than immediately purchasing or reinstalling another certificate.

1. The Certificate Has Expired

One of the simplest SSL problems is an expired certificate. Every publicly trusted TLS certificate has a defined validity period, and once the Not After date has passed, clients can reject it.

A browser may display an error such as:

NET::ERR_CERT_DATE_INVALID

The exact message varies between browsers, operating systems, and applications.

This problem is particularly common when certificates are renewed manually. An administrator may successfully obtain a replacement certificate but forget to deploy it to the server that actually handles HTTPS traffic.

For example, a website might have a new certificate installed on its origin server while an older certificate is still being served by a CDN or load balancer. From the administrator's perspective, the new certificate exists, but visitors continue receiving the old one.

How to fix it

Check the certificate currently being presented to visitors rather than checking only the certificate files stored on the server.

Verify:

1. The certificate's expiration date.
   
2. The hostname covered by the certificate.
   
3. Which server is terminating TLS.
   
4. Whether a CDN or load balancer is serving a different certificate.
   
5. Whether the renewed certificate has actually been deployed.

Certificate monitoring and automated renewal can significantly reduce this type of failure.

2. The Certificate Does Not Match the Domain

A certificate must cover the hostname that the visitor is requesting.

For example, a certificate issued for:

example.com

does not automatically cover:

shop.example.com

unless the appropriate hostname is included in the certificate's Subject Alternative Name (SAN) entries or the certificate uses a suitable wildcard configuration.

A hostname mismatch can produce errors such as:

NET::ERR_CERT_COMMON_NAME_INVALID

This frequently occurs after moving websites between servers or adding new subdomains.

For example, an administrator may install the certificate for example.com but forget that customers access the application through portal.example.com.

How to fix it

Open the certificate details and check the SAN entries. Confirm that every hostname requiring HTTPS is covered.

Also check the web server configuration. On Nginx, verify the appropriate server_name configuration. On Apache, check ServerName and ServerAlias. If multiple websites share the same server, make sure the correct virtual host is selected for the requested hostname.

For a deeper troubleshooting process, see this guide to ERR_CERT_COMMON_NAME_INVALID and how to fix it.

3. The Wrong Certificate Is Being Served

A particularly confusing problem occurs when the correct certificate exists on the server, but visitors receive a different certificate.

This commonly happens on servers hosting multiple websites. HTTPS connections use Server Name Indication, or SNI, to identify the hostname requested by the client. The server then selects the certificate associated with that hostname.

If the virtual host configuration is incorrect, the server may return a default certificate instead.

For example:

A visitor requests:

secure.example.com

But the server returns a certificate issued for:

anotherdomain.com

The certificate itself may be completely valid. It is simply the wrong certificate for that connection.

How to fix it

Check the HTTPS virtual host or server block and verify that:

• The correct hostname is configured.
  
• The correct certificate file is referenced.
  
• The correct private key is referenced.
  
• The correct certificate is associated with the relevant virtual host.
  
• The web server has been reloaded after configuration changes.

If a CDN, reverse proxy, or load balancer sits in front of the origin server, check its certificate configuration as well.

4. The Certificate Chain Is Incomplete

A TLS certificate does not normally stand alone. Publicly trusted certificates are generally validated through a chain that connects the website certificate to a trusted root Certificate Authority.

A typical chain contains:

Server certificate → Intermediate CA → Trusted root

One of the most common installation mistakes is uploading only the server certificate and forgetting to configure the required intermediate certificate.

The result can be inconsistent. Some browsers may successfully build a trust path using cached or otherwise available intermediate information, while certain applications, APIs, command-line tools, or older systems may fail.

Common messages include:

unable to get local issuer certificate

or

certificate verify failed

This is one reason a website can appear to work normally in Chrome while an API client, mobile application, or command-line tool fails.

How to fix it

Install the complete certificate chain provided by the Certificate Authority. On many server configurations, this means using the appropriate full-chain certificate bundle rather than uploading only the leaf certificate.

You can learn more about how certificates are connected through the SSL certificate chaining process.

5. The Private Key Does Not Match the Certificate

Every SSL/TLS certificate is associated with a private key. The certificate contains the public key, while the private key remains on the server or within the relevant certificate management system.

If the wrong private key is paired with the certificate, the server may be unable to establish a successful TLS connection.

This can happen when administrators move a certificate between servers and accidentally use an old key, install files from different certificate requests, or overwrite key files during a migration.

How to fix it

Verify that the certificate and private key belong to the same key pair.

If you generated a new Certificate Signing Request during renewal, make sure the resulting certificate is installed with the corresponding private key. Do not assume that any private key on the server will work with the new certificate.

If the original private key is unavailable, the appropriate solution may be to generate a new key pair and obtain a replacement certificate.

6. Mixed Content Appears After HTTPS Installation

Sometimes the certificate is working correctly, but the website still displays security warnings.

This happens when an HTTPS page loads resources over HTTP.

For example:

https://example.com

might load an image from:

http://example.com/images/banner.jpg

The page itself uses HTTPS, but the resource does not.

Mixed content can affect images, JavaScript, CSS files, fonts, videos, iframes, and other resources. Active mixed content, particularly scripts, can also be blocked by browsers and cause parts of the website to stop working.

This is not usually a certificate failure. The certificate can be completely valid while the website contains insecure resource URLs.

How to fix it

Open the browser's Developer Tools and check the Console for mixed-content warnings.

Then search the website's:

• HTML
  
• CSS
  
• JavaScript
  
• Database
  
• CMS settings
  
• Theme files
  
• Plugins
  
• CDN configuration

Replace insecure http:// resource URLs with https:// versions where appropriate.

For a detailed troubleshooting process, see Mixed Content Errors: Causes, Types & Fixes for HTTPS.

7. HTTPS Redirects Create an Infinite Loop

Another common problem occurs when HTTP is redirected to HTTPS incorrectly.

Instead of:

HTTP → HTTPS → Website

the browser may experience:

HTTP → HTTPS → HTTP → HTTPS

and continue repeating the process until it gives up.

The browser may display:

ERR_TOO_MANY_REDIRECTS

This can happen when multiple systems are managing redirects at the same time. A WordPress plugin, .htaccess rule, Nginx configuration, CDN, or reverse proxy may each attempt to force HTTPS.

Cloud-based deployments can create another common scenario. For example, the CDN may communicate with the origin using HTTP while the origin expects HTTPS, causing the two systems to disagree about the connection state.

How to fix it

Check every layer responsible for redirects.

Look at:

WordPress URL settings

.htaccess

Nginx configuration

Apache virtual hosts

CDN settings

Reverse proxy configuration

Load balancer rules

There should be one clear HTTPS redirect strategy rather than multiple competing rules.

If you need to configure the redirect itself, see this guide on redirecting a website from HTTP to HTTPS.

8. The Certificate Works on One Domain Version but Not Another

Website owners often assume that example.com and www.example.com are automatically covered by the same certificate.

That depends on the certificate configuration.

A certificate may include both names:

example.com

www.example.com

But if only one hostname is covered, the other can generate a certificate warning.

The same issue applies to subdomains such as:

shop.example.com

api.example.com

mail.example.com

portal.example.com

How to fix it

Determine which hostnames actually need HTTPS and verify that each is covered by the certificate.

You can use a SAN certificate when several specific hostnames need protection, or a wildcard certificate when the architecture calls for broad coverage of subdomains under the same domain.

Also make sure DNS points each hostname to the infrastructure that has the corresponding certificate.

9. The Server Uses an Incompatible TLS Configuration

Not every HTTPS problem is directly related to the certificate.

The TLS protocol configuration also determines whether a client and server can establish a secure connection.

A server with outdated protocol versions, incompatible cipher settings, or an incorrect TLS configuration can produce errors such as:

ERR_SSL_PROTOCOL_ERROR

or other handshake failures.

For modern websites, the TLS configuration should be reviewed alongside the certificate rather than treating the certificate as the only security component.

This becomes particularly important after server migrations. A new hosting environment may have different TLS defaults than the old server.

How to fix it

Review the web server's TLS configuration and verify that it supports currently appropriate protocol versions and cipher suites.

Also test the website from different clients. If browsers work but APIs or older systems fail, the problem may involve protocol or cipher compatibility rather than the certificate itself.

10. The Certificate Has Been Revoked

Expiration and revocation are different.

An expired certificate reaches the end of its normal validity period. A revoked certificate is deliberately invalidated before its scheduled expiration, usually because of circumstances such as private-key compromise, misissuance, or another reason defined by the Certificate Authority.

A revoked certificate can cause browsers and other clients to reject the HTTPS connection.

For site owners, this is not something that should be bypassed. The correct approach is to determine why the certificate was revoked and replace it with a properly issued certificate.

You can learn more about certificate revocation and how revocation mechanisms work in this guide to Certificate Revocation Lists and modern certificate revocation.

How to Diagnose an SSL Certificate Misconfiguration

When HTTPS breaks, avoid changing several settings at once. Start with the exact error and work backward.

Step 1: Check the certificate being served

Do not only inspect the certificate file stored on your server. Check the certificate that external visitors actually receive.

• Confirm the:
• Domain name
  
• SAN entries
  
• Expiration date
  
• Issuer
  
• Certificate chain
  
• Public key

Step 2: Identify where TLS terminates

Determine whether HTTPS terminates at:

The web server

• A CDN
  
• A reverse proxy
  
• A load balancer
  
• A cloud platform
  
• An application gateway

The certificate you need to troubleshoot is the one presented at the TLS termination point.

Step 3: Check the certificate chain

If browsers work but APIs, command-line tools, or applications fail, investigate the intermediate certificate configuration.

An incomplete chain is a common cause of client-specific SSL failures.

Step 4: Check the hostname

Confirm that the hostname in the browser address bar appears in the certificate's SAN entries.

Do not assume that a certificate for the root domain automatically covers every subdomain.

Step 5: Check redirects

Use browser Developer Tools or command-line testing to determine whether HTTP and HTTPS are redirecting correctly.

If the site repeatedly switches between protocols, inspect the CDN, proxy, web server, and CMS configuration.

Step 6: Check for mixed content

If HTTPS loads but the browser shows a warning, inspect the Console for insecure resources.

This separates a certificate problem from a website-content problem.

Step 7: Test from multiple clients

A website should not be tested only from one browser on one computer.

Test:

Chrome

Firefox

Safari where applicable

Mobile devices

API clients

curl

External TLS testing tools

Different clients can expose different certificate-chain and TLS compatibility problems.

How to Prevent SSL Certificate Misconfiguration

The best SSL configuration is one that does not depend on someone remembering every renewal and deployment step manually.

Maintain an inventory of certificates, domains, expiration dates, private keys, issuing CAs, and deployment locations. This becomes increasingly important when certificates are distributed across cloud servers, CDNs, load balancers, Kubernetes clusters, and multiple hosting environments.

Automated renewal is useful, but renewal alone is not enough. The renewed certificate also needs to reach the infrastructure that actually handles HTTPS traffic.

Organizations should therefore monitor both certificate expiration and certificate deployment. A certificate can be renewed successfully while the website continues serving an older certificate.

It is also important to understand the fundamentals of SSL and TLS, especially when troubleshooting problems that appear to be certificate failures but are actually related to TLS configuration.

Final Thoughts

An SSL certificate misconfiguration can range from a simple expired certificate to a more complicated problem involving certificate chains, private keys, DNS, SNI, redirects, CDNs, or TLS protocol settings.

The important point is that not every HTTPS error means you need a new certificate. Replacing a valid certificate will not fix a missing intermediate certificate, an incorrect virtual host, a redirect loop, mixed content, or an incompatible TLS configuration.

The fastest way to resolve an SSL problem is to identify exactly what the client is receiving, read the actual browser or application error, and then trace the connection through the certificate, chain, hostname, server configuration, and infrastructure in front of the server.

When SSL/TLS is treated as an entire connection and certificate lifecycle rather than a single certificate file, diagnosing HTTPS problems becomes much more predictable.

Frequently Asked Questions

What is the most common SSL certificate misconfiguration?

Common problems include expired certificates, hostname mismatches, incomplete certificate chains, incorrect certificate deployment, and improperly configured HTTPS redirects. Mixed content is also common after migrating a website from HTTP to HTTPS.

Why does my SSL certificate show as valid but my website still has an HTTPS error?

A valid certificate does not guarantee a correct HTTPS configuration. The problem could be mixed content, an incorrect redirect, an incomplete certificate chain, a wrong virtual host, a CDN configuration issue, or an incompatible TLS setting.

Why does my SSL certificate work in Chrome but fail in an API?

The API client may use a different trust store or TLS implementation. An incomplete certificate chain is one possible cause, although protocol, cipher, proxy, or client trust-store differences can also be responsible.

Does an SSL certificate automatically secure every subdomain?

No. The certificate must cover the requested hostname. Depending on the certificate, this may be done through individual SAN entries or an appropriate wildcard certificate.

Can installing a new SSL certificate fix every HTTPS error?

No. Certificate replacement only solves problems associated with the certificate itself. Configuration problems involving redirects, mixed content, DNS, TLS protocols, certificate chains, or CDNs require configuration changes.

How can I check whether my SSL certificate is configured correctly?

Check the certificate being served publicly, including its hostname, expiration date, issuer, SAN entries, and certificate chain. Then test HTTPS from multiple clients and review browser or application error messages. A TLS testing service can also help identify server-side configuration problems.