How to Fix SSL Certificate Not Working
If your site is showing a certificate warning, broken HTTPS padlock, or an SSL handshake failure, the problem usually comes down to trust, configuration, or expiration.
This guide explains how to fix SSL certificate not working issues by checking the most common causes first and then moving into deeper server-side troubleshooting.
SSL and TLS protect data in transit, but even a small mismatch between a certificate, hostname, chain, or server setting can break the connection.
The good news is that most SSL errors are fixable without replacing your entire site setup.
What “SSL Certificate Not Working” Usually Means
When users say an SSL certificate is not working, they may be seeing different errors across browsers, apps, or API clients.
Common symptoms include “Your connection is not private,” “certificate not trusted,” “NET::ERR_CERT_COMMON_NAME_INVALID,” or a browser loading the site over HTTP instead of HTTPS.
In practice, these issues often involve one or more of the following:
- The certificate has expired or is not yet valid.
- The certificate does not match the domain name or subdomain.
- The intermediate certificate chain is incomplete.
- The server is using an outdated TLS version or weak cipher suite.
- DNS, proxy, or CDN settings are pointing to the wrong origin.
- The certificate was installed on the wrong virtual host or load balancer.
Check the Certificate Status First
Start by confirming whether the certificate is active and valid.
Open the site in a browser and view the certificate details, or use a command-line tool such as OpenSSL to inspect the certificate from the server.
Look for these key fields:
- Expiration date — if the certificate is expired, renew it immediately.
- Subject Alternative Name (SAN) — the domain or subdomain must be listed here.
- Issuer — verify that the certificate comes from a trusted certificate authority such as Let’s Encrypt, DigiCert, Sectigo, or GlobalSign.
- Serial number and fingerprints — useful for confirming you installed the intended certificate.
If the certificate is expired, renewal is the fastest fix.
For Let’s Encrypt, the certificate is typically renewed automatically through tools such as Certbot, but automation can fail if cron, permissions, or DNS validation is broken.
Verify the Domain Name Matches the Certificate
A very common reason SSL appears broken is hostname mismatch.
A certificate issued for www.example.com will not automatically secure example.com unless both names are included in the SAN list.
Check whether your site is accessible through multiple versions of the domain:
- example.com
- www.example.com
- m.example.com
- app.example.com
If users can reach the site through any of these hostnames, each one must be covered by the certificate or redirected to a covered hostname.
This is especially important on platforms that serve both apex domains and subdomains.
Inspect the Certificate Chain
Even when the leaf certificate is valid, browsers may still reject it if the intermediate chain is incomplete.
The server should present the full chain, usually including the leaf certificate plus any intermediate certificates required to connect the site certificate to a trusted root CA.
Signs of a chain problem include warnings that the certificate is not trusted on some devices but works on others.
Older Android versions, embedded systems, and enterprise environments are more sensitive to incomplete chains.
To fix this, reinstall the certificate bundle provided by your certificate authority or hosting provider.
On many systems, the server needs a combined full-chain file rather than only the server certificate.
Confirm the Server Is Serving the Correct Certificate
On shared hosting, reverse proxies, and multi-site servers, the wrong certificate may be attached to the wrong virtual host.
This can happen when SNI, server blocks, or listener rules are misconfigured.
Make sure the SSL certificate is bound to the correct:
- IP address and port 443 listener
- Apache virtual host or Nginx server block
- Load balancer target group
- CDN edge configuration
If your site uses Server Name Indication, the client and server must negotiate the correct hostname during the TLS handshake.
Without the right SNI configuration, users may receive a default certificate that belongs to another domain.
Check TLS Protocol and Cipher Settings
SSL problems are often really TLS configuration problems.
Modern browsers require secure protocol versions such as TLS 1.2 or TLS 1.3.
If your server only supports older protocols like SSL 3.0, TLS 1.0, or TLS 1.1, many clients will fail the connection.
Review your web server configuration and disable obsolete protocols.
Also confirm that your cipher suite list includes modern, secure options that current browsers and operating systems accept.
Use current TLS standards on servers such as:
- Apache
- Nginx
- Microsoft IIS
- LiteSpeed
- Caddy
Outdated OpenSSL packages can also cause negotiation failures, especially after operating system upgrades or cryptography policy changes.
Look for DNS, CDN, and Proxy Problems
Your certificate may be correct, but traffic could be going somewhere else.
DNS records, Cloudflare settings, application firewalls, and reverse proxies can all affect which certificate users see.
Common issues include:
- DNS A or AAAA records pointing to the wrong server
- A CDN serving an old certificate after renewal
- Proxy SSL mode set incorrectly, such as flexible instead of full or full strict
- Load balancers terminating TLS with a different certificate than the origin
If you use Cloudflare, AWS CloudFront, Fastly, Azure Front Door, or a similar edge platform, verify both the edge certificate and the origin certificate.
The edge may be secure while the origin connection still fails.
Renew or Reissue the Certificate
If the certificate is expired, revoked, or issued with the wrong names, renewal or reissuance may be required.
Reissuance is common when adding a subdomain, changing a hosting provider, or correcting SAN entries.
Before renewing, confirm ownership of the domain through HTTP, DNS, or email validation depending on the CA and your workflow.
If you use an automated ACME client, check whether validation challenges are completing successfully and whether the certificate is being installed after issuance.
After renewal, clear cached certificates on proxies, restart the web server if needed, and re-test from multiple devices.
Test the Fix from Multiple Tools
Do not rely only on a browser test.
A certificate can appear fixed on one device and still fail elsewhere.
Validate the site from different environments and network paths.
Useful checks include:
- Browser certificate details in Chrome, Firefox, or Safari
- openssl s_client for direct handshake inspection
- SSL testing tools such as SSL Labs by Qualys
- Command-line checks from a mobile or external network
Look for hostname mismatches, incomplete chains, expired intermediates, weak ciphers, and protocol negotiation errors.
If the site passes from one location but not another, the issue may be DNS propagation, caching, or an edge-node mismatch.
Why SSL Breaks After a Migration or Server Change
SSL certificate problems often appear right after a migration to a new host, a switch to Nginx, a control panel upgrade, or a move to a CDN.
During migrations, administrators may forget to copy the full certificate chain, private key, or vhost configuration.
Other migration-related causes include:
- Old certificate files still referenced in configuration
- Private key and certificate not matching
- Redirect loops between HTTP and HTTPS
- Firewall or security group blocking port 443
- Missing SAN entries for staging and production domains
When moving infrastructure, verify SSL last only after the new server is already reachable, but before DNS is fully switched over.
Prevent SSL Certificate Problems in the Future
Once you fix the immediate issue, set up controls that reduce future outages.
Automating renewal and monitoring expiration dates are the most effective ways to prevent recurring SSL failures.
Best practices include:
- Enable auto-renewal for ACME-based certificates.
- Monitor expiration dates with alerts at 30, 14, and 7 days.
- Document certificate locations, private key paths, and renewal steps.
- Use a single source of truth for domain names and SANs.
- Re-test SSL after every deployment, migration, or proxy change.
For larger environments, certificate management platforms and centralized secret stores can reduce human error and make renewals more reliable.
When to Escalate the Problem
If you have verified expiration, hostname matching, chain installation, and server configuration but SSL still fails, the issue may involve an upstream platform, a malformed certificate file, or a private key mismatch.
In that case, compare the certificate fingerprint on the server with the one issued by the CA and review server logs for handshake errors.
Hosting providers, CDN support teams, and certificate authorities can often identify the exact failure point if you provide the domain, error message, certificate fingerprint, and test results from SSL Labs or OpenSSL.