Why SSL Isn’t Working: Expired Certificate, Mixed Content, Redirect Loop, and DNS Errors

If SSL isn’t working, first identify the symptom. Different errors may look similar to users, but they are fixed in different places: DNS, the certificate, the web server, redirects, the CMS, the CDN, or the certificate chain.

Diagnostic table:

The key point is not to start with the CMS. WordPress, Bitrix, or another CMS can store the site address, perform redirects, and return links to resources, but SSL works at a lower level: DNS, the web server, the certificate, and the HTTPS connection.

The basic check sequence is as follows:

1. Check the time on the computer and make sure the issue is actually on the server side.
2. Check where the domain points:

dig +short example.com

dig +short www.example.com

2. Check which certificates Certbot knows about, if it is being used: sudo certbot certificates
3. Check the web server configuration: sudo nginx -t or sudo apachectl configtest
4. Check the HTTP and HTTPS responses:

curl -I http://example.com

curl -I https://example.com

5. Check which certificate the server is actually serving: openssl s_client -connect example.com:443 -servername example.com
6. Check the web server logs if the error is not clear from the external symptoms.

Common mistakes when fixing SSL include changing only the CMS settings, forgetting about www and non-www, not checking the certificate chain, and enabling redirects simultaneously in the control panel, CMS, web server, and CDN.

The right approach is simpler: first identify the symptom, then check DNS, the certificate, the web server, and redirects, and only after that change the site or CDN settings.

How to Quickly Diagnose an SSL Issue

When SSL fails, the first reaction is often the wrong one: logging in to the CMS, changing the site address, enabling yet another redirect, or clicking the certificate issuance button in the control panel again.

This can accidentally complicate the problem. It is better to proceed step by step: first identify the symptom, then check DNS, the certificate, and the web server, and only then make changes to the CMS, CDN, or plugins.

First, identify the symptom

The phrase “SSL is not working” is too vague. It can refer to different issues: an expired certificate, an incorrect domain, a redirect loop, mixed content, a protocol error, or a conflict with a CDN.

First, record exactly what the user sees:

• The browser reports “certificate expired”;
• The site opens only over HTTP;
• An error appears when accessing the site over HTTPS;
• The page redirects indefinitely;
• The browser shows mixed content;
• The certificate was issued for a different domain;
• The certificate is not trusted;
• The error appeared after enabling Cloudflare or another CDN.

This matters because different symptoms lead to different checks. For example, “certificate expired” is more often related to auto-renewal, while a redirect loop is caused by conflicting redirects in the web server, CMS, control panel, or CDN.

Mixed content does not mean that the certificate is not installed. In this case, HTTPS may be working correctly, but some resources on the page are still being loaded over HTTP.

The first step, therefore, is not to “reinstall SSL,” but to identify the exact symptom. After that, troubleshooting becomes much easier.

Check the client device first

In most cases, the server and certificate are fine, and the issue is purely local. A quick checklist:

• Check the time on the device;
  
• Check whether the site opens correctly on another device, preferably using a different ISP;
  
• Clear the browser cookies and cache, or use a different browser, then run the check again.

If the issue still persists and occurs on different devices with different ISPs, you need to start diagnosing the server side.

Then check DNS, the certificate, and the web server

After identifying the symptom, check the basic chain: the domain, the certificate, and the web server.

Start with DNS. The domain should point to the VPS or CDN that actually serves the site:

dig +short example.com

dig +short www.example.com

If example.com and www.example.com point to different IP addresses, the error may appear only on one version of the site.

Next, check the certificates known to Certbot: sudo certbot certificates

This command shows which domains a certificate was issued for, where its files are stored, and when it expires.

Then check the web server configuration. For Nginx: sudo nginx -t

For Apache: sudo apachectl configtest

If the configuration is broken, HTTPS may not work even with a valid certificate.

Next, check the site’s responses:

curl -I http://example.com

curl -I https://example.com

This lets you see status codes, redirects, and the Location header. If there is a redirect loop, curl will quickly show where the server is trying to redirect the request.

To check the certificate actually served by the server, use: openssl s_client -connect example.com:443 -servername example.com

This is especially useful if the browser shows a certificate for a different domain or a certificate chain error.

If external checks do not provide an answer, move on to the web server logs. For Nginx, you typically check the access and error logs; for Apache, the relevant virtual host logs or the general error logs.

This sequence helps avoid guesswork: first DNS, then the certificate, then the configuration, server responses, and logs.

Why You Shouldn’t Fix SSL in the CMS Alone

A CMS can contribute to the problem, but it is rarely the only layer where SSL operates.

WordPress, Bitrix, Drupal, or another CMS can store the site address, generate links, enable redirects, serve images, and load stylesheets and scripts. However, HTTPS itself works at a lower level: DNS, the web server, the certificate, and the TLS connection.

If the certificate has expired, changing the site address in the CMS will not help. If the domain points to the wrong IP address, an HTTPS plugin will not fix it either. If SSL is not configured on port 443, the CMS may be fully functional, but the browser will still display an error.

It makes sense to check the CMS after basic diagnostics. For example, when the certificate is valid, the site loads over HTTPS, and the redirect works, but HTTP links remain on the pages. In that case, the issue may be in the site settings, database, template, plugins, or cache.

A CMS is also often the source of a redirect loop. For example, a redirect may be enabled in the control panel, in Nginx, in a WordPress plugin, and also at the CDN. Each layer tries to “help,” but together they create an infinite redirect.

The correct approach is therefore to check the infrastructure first, and then the CMS. SSL should not be fixed from the top layer down, but from the foundation up: DNS, certificate, web server, redirects, CDN, and only then the site settings.

Symptom-Based Diagnostic Tree

SSL issues are easier to troubleshoot by asking “what exactly does the user see?” rather than “what should be reinstalled?” A single symptom usually narrows the possible causes down to a few checks.

Below are the main scenarios, from an expired certificate to errors after enabling a CDN.

The browser reports “certificate expired”

The “certificate expired” message means that the browser is seeing a certificate whose validity period has expired. If the certificate is paid and was installed manually, it must be replaced. When using free LE certificates, this most often happens when Certbot automatic renewal fails or the web server continues to serve the old certificate.

First, check the certificates on the server: sudo certbot certificates

The command will show the domains, certificate paths, and expiration dates. If the certificate has actually expired, you need to check why it was not renewed.

Then run an automatic renewal test: sudo certbot renew –dry-run

If the dry run fails, the cause may be DNS, port 80 being closed, a misconfigured virtual host, a redirect conflict, or an issue with the DNS challenge for a wildcard certificate.

You should also check which certificate the server is actually serving:

openssl s_client -connect example.com:443 -servername example.com

Sometimes Certbot has already renewed the certificate, but Nginx or Apache has not been reloaded and continues to serve the old file. In that case, check the configuration and reload the web server.

For Nginx:

sudo nginx -t

sudo systemctl reload nginx

For Apache:

sudo apachectl configtest

sudo systemctl reload apache2

If the browser still shows the old certificate after the reload, check the CDN, reverse proxy, and cache. The user may be seeing the certificate from an intermediate layer rather than the origin server’s certificate.

The website loads without HTTPS

If a site loads over HTTP but does not redirect to HTTPS, it does not always mean that SSL is “not installed.” Sometimes the certificate is present, but the redirect is not configured or the certificate is assigned to the wrong virtual host.

First, check the HTTP response: curl -I http://example.com

If the server returns 200, the site is being served over HTTP without a redirect. For a permanent redirect, you would typically expect 301 or 302 with a Location: https://… header.

Then check HTTPS: curl -I https://example.com

If HTTPS works but HTTP does not redirect, the issue is with the redirect. It needs to be configured in Nginx, Apache, the control panel, or the CDN—but it is better to choose one primary layer rather than enabling redirects everywhere at once.

If HTTPS does not work at all, check whether the certificate is assigned to the correct server block or virtual host.

For Nginx, check the configuration: sudo nginx -t

Then find the block for the domain: grep -R "server_name example.com" /etc/nginx/sites-enabled /etc/nginx/conf.d

For Apache, check the virtual host: sudo apachectl -S

If the domain is being served by the wrong configuration, the server may serve the site over HTTP but not have HTTPS correctly configured for that hostname.

Up to €20,000 in EU-Based IaaS Credits

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get

Infinite HTTP ↔ HTTPS Redirect Loop

A redirect loop occurs when a request goes in circles: the server, CMS, control panel, or CDN keeps redirecting the user but never reaches the final URL.

A common cause is having redirects enabled in multiple places at once. For example, HTTPS may be enabled in the control panel, a CMS plugin, the Nginx configuration, and Cloudflare. Each layer tries to correct the URL scheme, but together they create a loop.

You can check the redirect chain as follows: curl -I -L http://example.com

The -L flag shows the redirect hops. If URLs repeat or the site switches back and forth between http and https, the issue is a conflict between rules.

Separately, check where the different domain versions redirect:

curl -I http://example.com

curl -I http://www.example.com

curl -I https://example.com

curl -I https://www.example.com

The redirect should be consistent and predictable. For example:

http://example.com → https://example.com

http://www.example.com → https://example.com

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

Or vice versa, if the primary domain is configured with www.

If you use a CDN, check the SSL mode and forced HTTPS settings. With an incorrect configuration, the CDN may connect to the origin server over HTTP, while the origin server redirects it back to HTTPS. This creates a loop.

It is better to keep the primary redirect in one place: either on the web server or in the CDN. The CMS should store the correct site URL, but it does not always need to be the main mechanism for HTTPS redirects.

The browser shows mixed content

Mixed content is a situation where the main page opens over HTTPS, but some resources are loaded over HTTP.

For example: https://example.com

And the page contains a resource: http://example.com/uploads/banner.jpg

In this case, the certificate may be fully valid. The issue is not with SSL issuance, but with the links within the site.

The easiest way to check for mixed content is through the browser’s DevTools. Open the Console or Network tab and look for resources that are loaded over http://.

Most often, these are:

• Images;
• CSS files;
• JavaScript;
• Fonts;
• iframes;
• Videos;
• API requests;
• External widgets.

In the CMS, check the site URL, theme, plugins, cache, and old links in the database. In WordPress, for example, mixed content often remains after migrating from HTTP to HTTPS if old absolute links were not replaced.

Also check external resources. If a third-party script or widget does not support HTTPS, the browser may block it or show a warning.

Mixed content is not fixed by reissuing the certificate, but by moving all internal and external resources to HTTPS.

ERR_SSL_PROTOCOL_ERROR is displayed

ERR_SSL_PROTOCOL_ERROR usually means that the browser tried to connect over HTTPS, but the server could not establish the TLS connection correctly.

There can be several causes: SSL is not configured on port 443, the web server is serving plain HTTP on the HTTPS port, the configuration is broken, the certificate is installed incorrectly, or the CDN is conflicting with the origin server.

First, check whether HTTPS is responding: curl -I https://example.com

Then check the web server configuration.

For Nginx: sudo nginx -t

For Apache: sudo apachectl configtest

If the configuration is valid, check what is listening on port 443: sudo ss -tulpn | grep :443

It is also useful to inspect the certificate with OpenSSL: openssl s_client -connect example.com:443 -servername example.com

If OpenSSL cannot establish a connection, the problem is below the CMS layer: in the web server, TLS configuration, firewall, CDN, or network rules.

After that, check the logs.

For Nginx: sudo tail -n 50 /var/log/nginx/error.log

For Apache: sudo tail -n 50 /var/log/apache2/error.log

ERR_SSL_PROTOCOL_ERROR should not be fixed by replacing the URL in the CMS. First, make sure that port 443 is actually serving HTTPS.

The certificate was issued for a different domain

If the browser says that the certificate was issued for a different domain, the server is presenting the wrong certificate or the user is reaching the wrong virtual host.

A common cause is forgetting to include www, a subdomain, or an alternative name when issuing the certificate.

If you use certbot, check which domains are included in the certificate: sudo certbot certificates

Then check which certificate the server is actually presenting: openssl s_client -connect example.com:443 -servername example.com

If the problem occurs only on www, check it separately: openssl s_client -connect www.example.com:443 -servername www.example.com

Also check DNS:

dig +short example.com

dig +short www.example.com

If example.com and www.example.com point to different IP addresses, the browser may receive certificates from different servers.

On the web server side, verify that the target domain has its own server block or virtual host, and that the correct certificate is configured there.

For Nginx, it is useful to find all references to the domain: grep -R “example.com” /etc/nginx/sites-enabled /etc/nginx/conf.d

For Apache: sudo apachectl -S

If the server presents the default certificate, this means the request is not reaching the correct virtual host or the correct server_name/ServerName is not specified in the configuration.

Certificate not trusted

If the browser refuses to open the site because of a trust error, and curl does not work without the -k option, the problem is most likely with building the chain of trust.

You need to check the certificate that the site actually presents – openssl s_client -connect www.example.com:443 -servername www.example.com

You can even save it as a separate file and open it in system applications. In most cases, trust errors occur when the certificate is not fully installed on the server (for example, when only one certificate is installed instead of the fullchain), when the system does not trust the certificate authorities that issued the certificate, or when the certificate is self-signed (not purchased, not issued through certbot, but generated manually).

A less common error occurs when the certificate authority has revoked the certificate for some reason.

In any case, you need to check the web server configuration and, if necessary, reissue the certificate.

The error appeared after enabling Cloudflare or a CDN

If SSL stopped working after you enabled Cloudflare or another CDN, the issue may not be on the VPS, but between the CDN and the origin server.

A CDN adds another layer: the user connects to the CDN, and the CDN separately connects to your VPS. This makes the selected SSL mode important, as well as whether the origin server has a valid certificate.

Common causes:

• The wrong SSL mode is selected;
• The CDN connects to the origin over HTTP, while the server requires HTTPS;
• The origin certificate has expired;
• The certificate on the VPS was issued for a different domain;
• Redirects are enabled both in the CDN and on the server;
• DNS records are proxied, but the server is configured for direct access.

It is best to start by checking the CDN settings: SSL mode, Always Use HTTPS, Automatic HTTPS Rewrites, Page Rules, or Redirect Rules.

Then check the origin server directly, if you can access it without the CDN. This is sometimes done using a temporary record, the hosts file, or a direct request to the IP address with the required SNI.

Also check the standard responses:

curl -I http://example.com

curl -I https://example.com

And check the certificate: openssl s_client -connect example.com:443 -servername example.com

If the error disappears when the CDN is disabled, the problem is almost certainly in the CDN ↔ origin path: SSL mode, redirects, the server certificate, or DNS proxying.

When using a CDN, it is especially important not to enable redirects everywhere at the same time. It is better to choose one primary layer for enforcing HTTPS and make sure the origin server also has a valid certificate.

After following this diagnostic tree, you can move on to tools. They help not only identify the symptom, but also confirm the cause: DNS shows where the domain points, Certbot shows which certificates exist on the server, curl shows how redirects work, and openssl s_client shows which certificate is actually served to the user.

Commands that help identify the cause

Once the symptom is clear, the next step is to confirm the cause. You do not need to change the configuration or reissue the certificate right away. A few checks are often enough: DNS, Certbot, the web server, HTTP responses, the actual certificate, and logs.

These commands help identify exactly where the chain breaks: domain → server → certificate → web server → redirect → browser.

Where the Domain Currently Points

DNS shows where the domain currently points. This is the first thing to check if the site loads from the wrong server, a certificate cannot be issued, or the error appears only on www or only on the root domain.

You can check the A record as follows: dig +short example.com

For www: dig +short www.example.com

If IPv6 is used, you should also check the AAAA record: dig +short AAAA example.com

It is important to compare the result with the IP address of your VPS or CDN. If the domain points to a different IP address, the SSL issue needs to be fixed in the DNS zone, not in Certbot or the CMS.

You should also check both versions of the domain. A common situation is when example.com points to the new VPS, while www.example.com still points to the old server. As a result, one version of the site works, while the other serves someone else’s certificate or an expired certificate.

Which certificates Certbot can see

Full Control Over Your Kubernetes Infrastructure

Deploy production-ready Kubernetes with full control over nodes, storage, and networking on predictable-cost EU infrastructure with direct access to your resources.

Get

If the certificate was issued through Certbot, you can view the list of certificates with this command:

sudo certbot certificates

It shows:

• The certificate name;
• The domains it was issued for;
• The expiration date;
• The path to fullchain.pem;
• The path to privkey.pem.

This command is useful when troubleshooting certificate expired errors, an incorrect domain in the certificate, and automatic renewal issues.

If the domain you need is not in the list, the certificate for it was not issued through this Certbot instance or has been deleted. If the domain is listed but the expiration date has passed, you need to check automatic renewal: sudo certbot renew –dry-run

If the dry run fails, the cause may be DNS issues, port 80 being closed, a misconfigured virtual host, a redirect loop, or a DNS challenge for a wildcard certificate.

Is Nginx or Apache configured correctly?

Even a valid certificate will not help if the web server is configured incorrectly. Therefore, after checking DNS and Certbot, you should verify the Nginx or Apache configuration.

For Nginx: sudo nginx -t

If the test passes, you can reload the configuration: sudo systemctl reload nginx

For Apache: sudo apachectl configtest

And then: sudo systemctl reload apache2

These checks are especially important for ERR_SSL_PROTOCOL_ERROR, errors after manually editing the configuration, and situations where a certificate exists but the site does not open over HTTPS.

It is also useful to identify which configuration file serves the domain.

For Nginx: grep -R "server_name example.com" /etc/nginx/sites-enabled /etc/nginx/conf.d

For Apache: sudo apachectl -S

This lets you see whether the domain is mapped to the correct server block or virtual host.

How the Server Responds to HTTP and HTTPS

curl helps you understand how a server responds to HTTP and HTTPS requests. It is the primary tool for checking redirects.

Checking HTTP: curl -I http://example.com

Checking HTTPS: curl -I https://example.com

If HTTP is supposed to redirect to HTTPS, the response is typically expected to include a 301 or 302 status code and a Location header:

Location: https://example.com/

To analyze the redirect chain, you can use: curl -I -L http://example.com

If there is a redirect loop, the command will show repeated redirects or an excessively long chain.

You should also check all domain variants separately:

curl -I http://example.com

curl -I http://www.example.com

curl -I https://example.com

curl -I https://www.example.com

This makes it easier to catch issues where the www and non-www versions behave differently.

Which certificate the browser receives

The browser shows an error, but it is not always easy to determine which certificate the server is actually presenting. You can use openssl s_client for this.

Basic command: openssl s_client -connect example.com:443 -servername example.com

The -servername parameter is important because multiple sites can share the same IP address. It sends SNI so the server selects the certificate for the correct domain.

With openssl, you can see:

• Which certificate the server presents;
• Which domain it was issued for;
• Who issued it;
• When it expires;
• Whether there are any problems with the certificate chain.

If you need to quickly check the certificate dates, you can use this command: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

To check the domains in the certificate: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 “Subject Alternative Name”

This helps with “certificate for a different domain” errors, certificate expired errors, and cases where you suspect that a CDN or reverse proxy is presenting the wrong certificate.

Checking Web Server Logs

If DNS, Certbot, curl, and openssl do not provide a complete picture, check the logs. They help identify web server errors, virtual host issues, TLS configuration problems, certificate file permission issues, and redirects.

For Nginx, you usually start with the error log: sudo tail -n 50 /var/log/nginx/error.log

And the access log: sudo tail -n 50 /var/log/nginx/access.log

For Apache: sudo tail -n 50 /var/log/apache2/error.log

And the access log: sudo tail -n 50 /var/log/apache2/access.log

If the site has separate virtual host logs configured, check those specifically. In control panels, the log path may vary, but it is usually shown in the site settings or in the web server configuration.

Logs are especially useful for ERR_SSL_PROTOCOL_ERROR, 502/503 errors after enabling HTTPS, reverse proxy issues, and situations where the browser shows a generic error without clear details.

After reviewing the logs, it usually becomes clear where to continue troubleshooting: DNS, Certbot, Nginx/Apache, the CMS, the CDN, or a specific redirect rule. The important thing is not to make fixes everywhere at once, but to change one layer at a time and check the result.

Common Mistakes When Fixing SSL

When HTTPS breaks, it can be tempting to quickly click “Fix SSL” in the control panel, change the site URL in the CMS, or reissue the certificate. Sometimes this helps, but it often creates new problems.

It is better to first determine where the issue lies: in DNS, the certificate, the web server, the CMS, the CDN, or redirects. Only then should you make changes to the specific layer involved.

Fixing SSL only in the CMS

A CMS can affect HTTPS, but it does not control the entire SSL chain. WordPress, Bitrix, Drupal, or another system can store the site address, generate links, perform redirects, and load resources. However, the certificate itself works at the web server and TLS level.

If the certificate has expired, changing the site address in the CMS will not renew it. If the domain points to the wrong IP address, an HTTPS plugin will not make Let’s Encrypt validation succeed. If SSL is not configured on port 443, the CMS will not fix the connection either.

You should check the CMS when basic HTTPS is already working, but issues remain within the site:

• Old HTTP links in the database;
• mixed content;
• Incorrect site URL;
• Conflicting redirect plugin;
• Old addresses in the cache;
• Absolute links in the template.

The correct order is: DNS, certificate, web server, and redirects first. Then the CMS, database, template, plugins, and cache.

Forgetting about www and non-www versions

To a user, example.com and www.example.com may look like the same site. For SSL, they are different domain names.

If a certificate is issued only for example.com, it will not automatically be valid for www.example.com. The reverse is also true: a certificate for www.example.com does not always cover the main version without www.

Therefore, when troubleshooting, you need to check both versions:

curl -I https://example.com

curl -I https://www.example.com

You should also check separately which domains are included in the certificate: sudo certbot certificates

A common mistake is to configure a redirect from www to non-www without including www in the certificate. In that case, a user who opens https://www.example.com gets a certificate error before the redirect occurs and never reaches the main version of the site.

It is better to choose the primary domain version in advance and redirect everything to it:

http://example.com → https://example.com

http://www.example.com → https://example.com

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

Or the other way around, if the primary version of the site should use www.

The key point is that the certificate must cover every domain from which a user may start their visit.

Failing to check the certificate chain

Sometimes a certificate appears to have been issued correctly, but the browser still shows a warning. The issue may not be with the domain itself, but with the certificate chain.

For the server to work correctly, it must serve not only the site certificate, but also the intermediate certificates. This is usually done with the fullchain.pem file, rather than only a separate domain certificate.

If the configuration points to an incomplete file, some browsers and clients may not trust the connection.

For Nginx, the path should usually point to the full chain:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

The same logic applies to Apache: the server must use the full chain, not an arbitrary certificate file. To do this, check the SSLCertificateFile and SSLCertificateKeyFile settings respectively; for older Apache versions, it is also important to add the intermediate certificates separately using the SSLCertificateChainFile directive.

You can check what the server actually serves using OpenSSL: openssl s_client -connect example.com:443 -servername example.com -showcerts

If the chain is incomplete, the issue may not affect all users at once. The site may open in one browser, show a warning in another, while an API client or mobile application may refuse to connect.

Therefore, after manually configuring SSL, it is important to check not only the certificate date and domain, but also that the server serves the correct chain.

Enabling redirects simultaneously in the control panel, CMS, and CDN

High-Performance Virtual Machines

Deploy in seconds with full root access, reserved resources, built-in high availability, and predictable monthly pricing.

Get

Infinite redirect loops often occur not because SSL is missing, but because too many “helpers” are involved.

For example, an HTTP → HTTPS redirect may be enabled:

• in the VPS control panel;
• in the Nginx or Apache configuration;
• in the CMS;
• in a security plugin;
• in Cloudflare or another CDN.

Each layer tries to redirect the user to the “correct” address. But if the rules differ, the site gets stuck in a loop: HTTP → HTTPS → HTTP, www → non-www → www, CDN → origin → CDN.

You can check the redirect chain like this: curl -I -L http://example.com

And separately for all domain versions:

curl -I http://example.com

curl -I http://www.example.com

curl -I https://example.com

curl -I https://www.example.com

It is better to choose one main layer for redirects. This is usually the web server or the CDN. The CMS should know the correct site address, but it does not necessarily need to manage the entire HTTPS redirection flow.

If the site is behind a CDN, you first need to understand how the CDN connects to the origin server: over HTTP or HTTPS, which SSL mode is enabled, and whether it conflicts with the rules on the server.

It is best to fix a redirect loop gradually: disable unnecessary redirects, leave one clear route, check it with curl, and then restore only the rules that are actually needed.

After fixing SSL, you should not assess the result only by checking the home page. You need to check both versions of the domain, HTTP and HTTPS, internal pages, forms, API requests, and assets. This makes it easier to confirm that the issue has been fixed, rather than simply hidden on a single URL.

What to Check After the Fix

After fixing SSL, do not stop at “the lock icon appears in the browser.” The error may be gone on the homepage but still remain on the www version, a subdomain, an internal page, an API, or in certificate auto-renewal.

First, check the main domain variants:

curl -I http://example.com

curl -I https://example.com

curl -I http://www.example.com

curl -I https://www.example.com

Make sure all variants lead to the correct final version of the site. For example, if the primary address is https://example.com, the other versions should redirect cleanly to it.

Then check which certificate the server returns: openssl s_client -connect example.com:443 -servername example.com

If www is used, check it as well: openssl s_client -connect www.example.com:443 -servername www.example.com

The certificate must be valid, issued for the correct domain, and include a proper certificate chain.

Next, check the list of Certbot certificates: sudo certbot certificates

And test auto-renewal: sudo certbot renew –dry-run

If the dry run fails, SSL cannot yet be considered fixed. The certificate may work now, but it will not renew automatically.

You should also open the site in a browser and check DevTools. The Console and Network tabs should show no mixed content, blocked HTTP resources, or loading errors for scripts, stylesheets, images, fonts, iframes, or API requests.

It is also worth checking the following separately:

• The homepage;
• Several internal pages;
• Login and request submission forms;
• The user account area, if there is one;
• API requests;
• Images and files from the media library;
• Subdomains;
• The CDN, if one is used;
• The mobile version of the site.

If the site runs through Cloudflare or another CDN, check not only the public address but also the CDN → origin connection. The error may disappear for users while still remaining between the CDN and the VPS.

After all checks are complete, it is useful to document the result: which domain is set as the primary one, where the redirect is configured, how the certificate was issued, whether auto-renewal works, and who is responsible for ongoing SSL maintenance.

Conclusion

SSL issues are almost always easier to troubleshoot by symptom. An expired certificate, mixed content, a redirect loop, a certificate for a different domain, and ERR_SSL_PROTOCOL_ERROR may look similar to the site owner, but they occur at different layers.

That is why you should not immediately reissue the certificate, change CMS settings, or add new redirects. First, you need to determine exactly what has failed: DNS, the certificate, the web server, the certificate chain, redirects, the CMS, or the CDN.

Basic diagnostics are built around several checks: dig shows where the domain points, certbot certificates shows which certificates are present on the server, curl -I shows how HTTP, HTTPS, and redirects behave, openssl s_client shows which certificate is actually being presented to the browser, and Nginx or Apache logs help identify hidden errors.

The most common issues are caused by simple oversights: forgetting about www, failing to verify automatic renewal, leaving mixed content in place, enabling redirects simultaneously in the control panel, CMS, and CDN, or trying to fix SSL only through site settings.

The right approach is to work from the bottom up: DNS, web server, certificate, HTTPS, redirects, CDN, and only then the CMS. This reduces the risk of accidentally making the problem worse and makes it easier to identify exactly where the root cause is.

SSL can be considered fixed only after a full verification: the site opens over HTTPS, all domain variants lead to the intended destination, the certificate is valid, the chain is correct, there is no mixed content left, and automatic renewal succeeds with certbot renew –dry-run.

FAQ

Why does the browser say the certificate has expired?

The browser shows “certificate expired” when the server presents an expired certificate or when the device’s clock is incorrect. This usually means automatic renewal did not work or the web server is still using the old certificate. If you are not using Certbot, check the certificate manually. If you are using Certbot:

First, check the Certbot certificates: sudo certbot certificates

Then check automatic renewal: sudo certbot renew –dry-run

If Certbot renewed the certificate but the browser still sees the old one, check whether Nginx or Apache was reloaded, the CDN, and which certificate is actually being served via openssl s_client.

Why does the site open over HTTP even though SSL is installed?

An SSL certificate does not always enable a redirect to HTTPS by itself. The certificate may be installed, but the server may still serve the site over HTTP without redirecting.

Check the response:

curl -I http://example.com

curl -I https://example.com

If the HTTP request returns 200 instead of 301 or 302, the redirect is not configured. You can configure it in Nginx, Apache, the control panel, or the CDN, but it is better not to enable redirects in multiple places at once.

What should you do if a redirect loop occurs after enabling HTTPS?

A redirect loop usually occurs when several layers try to redirect the site at the same time: the web server, control panel, CMS, security plugin, and CDN.

First, check the redirect chain: curl -I -L http://example.com

Then temporarily simplify the setup: keep a single primary redirect, for example at the Nginx, Apache, or CDN level. After that, test both www and non-www, as well as HTTP and HTTPS.

If you use Cloudflare or another CDN, check the SSL mode and HTTPS rules separately. Cloudflare manages two connections: one between the user and Cloudflare, and another between Cloudflare and the origin server, so the issue may lie in this connection chain.

Why does mixed content remain after enabling SSL?

Mixed content occurs when a page is loaded over HTTPS, but some resources are loaded over HTTP. These may include images, stylesheets, scripts, fonts, iframes, videos, or API requests.

The certificate itself may be valid. The issue lies in the links within the site, the template, CMS, database, cache, CDN, or external widgets.

MDN describes mixed content as a situation where a secure page uses resources that are loaded over HTTP or another insecure protocol.

Check the browser’s DevTools: the Console and Network tabs. All internal resources, forms, scripts, and APIs must use HTTPS.

How can you tell which certificate the server is actually presenting?

Use openssl s_client for this: openssl s_client -connect example.com:443 -servername example.com

The -servername parameter is important because multiple domains can share the same IP address. It sends SNI and helps the server select the certificate for the correct site.

To view the certificate dates: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

To check the domains in the certificate: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

This lets you determine whether the server is presenting the new certificate, whether the certificate has expired, and whether it is valid for the required domain.

Can Cloudflare break SSL?

Yes, if the SSL mode, redirects, or the certificate on the origin server are configured incorrectly.

For example, in Flexible mode, Cloudflare accepts HTTPS from the user but connects to the origin server over HTTP. This can create redirect conflicts and make the site appear to be “on HTTPS,” while the scheme between the CDN and the server is different.

In Full mode, Cloudflare uses an HTTPS connection between the visitor and Cloudflare, and also connects to the origin server using the scheme requested by the visitor.

If the error appeared after enabling the CDN, check the SSL mode, redirect rules, the certificate on the origin server, DNS proxying, and the “Always Use HTTPS” setting or similar features.

Do I need to reissue the certificate after changing the IP address?

A certificate is usually issued for a domain, not for an IP address. Therefore, after changing the IP address, the certificate does not always need to be reissued. If the IP address is included in the SAN, the certificate will need to be reissued.

In any case, you need to update the DNS records so that the domain points to the new VPS or the new origin server. After that, it is important to verify that the new server has a valid certificate and that the web server serves it for the correct domain.

If you have migrated the website to a new VPS, it is better not to blindly copy the old SSL configuration, but to check:

dig +short example.com

curl -I https://example.com

openssl s_client -connect example.com:443 -servername example.com

If the certificate is missing on the new server, has expired, or was issued for a different domain, you need to issue a new one.

Sources

1. Let’s Encrypt — Challenge Types

2. Certbot — User Guide

3. MDN Web Docs — Mixed content

4. Cloudflare Docs — SSL/TLS encryption modes