HTTPS is now standard for a professional website. It encrypts the connection between the browser and the web server and protects transmitted data from being read or modified unnoticed during transit.
That a website fundamentally via https:// being accessible, however, does not automatically mean that the entire HTTPS configuration is error-free.
An expired certificate, an incorrect hostname, mixed content, faulty redirects, or issues with the certificate chain can cause browsers to display security warnings or fail to load individual resources correctly.
In this article, we show you how to systematically investigate SSL/TLS and HTTPS problems and distinguish typical errors from each other.
Briefly explained: SSL certificates enable an encrypted HTTPS connection and confirm for which domain or hostname a certificate is valid. Therefore, when the browser displays an HTTPS warning, you should not only check whether a certificate is present at all, but also its validity, hostname, certificate chain, and the resources loaded by the website.
SSL and TLS: Which one is actually correct? #
In everyday life, people still often speak of a SSL certificate Spoken.
Technically, however, modern HTTPS connections use TLS. SSL refers to older predecessor protocols.
Terms such as:
SSL certificate
SSL encryption
SSL for websitenevertheless remain common in general usage.
For example, technically more precise would be:
TLS certificate
or
HTTPS connection with TLSIn this article, we use the common term SSL certificate where it facilitates understanding.
What does HTTPS do? #
During an HTTPS connection, the browser communicates with the server in an encrypted manner.
Simplified:
Browser
↓
TLS connection
↓
Verify identity / certificate
↓
Encrypted connection
↓
Web serverThis is intended in particular to protect the confidentiality and integrity of the transmitted data.
HTTP and HTTPS are different URL variants #
These two URLs look similar:
http://example.com/
Technically, however, these are different URL variants.
On a website that has been completely switched to HTTPS, the HTTP version should normally redirect cleanly to the corresponding HTTPS version.
For example:
http://example.com/beispiel/
↓
301 Permanent Redirect
↓
https://example.com/beispiel/We explain how permanent redirects work at Set up a 301 redirect: Permanently redirect URLs.
What is an SSL certificate? #
A certificate contains information needed for establishing and testing a secure connection.
This includes, among other things, information on which hostnames the certificate is valid for, who issued it, and the period for which it is valid.
A browser checks this information when establishing the HTTPS connection.
What information should you check on a certificate? #
When troubleshooting, the following points are particularly relevant:
Domain / Hostname
Issuer
Valid From
Valid To
Subject Alternative Names
Certificate Chain
TrustworthinessModern browsers provide some of this information via the security or certificate information or the developer tools.
The padlock symbol is not the whole diagnosis #
Browser interfaces change regularly. Depending on the browser and version, a secure connection is therefore not always displayed with the exact same icon.
Do not rely solely on a lock icon for technical diagnostics.
More important is:
Is https:// used?
Is the certificate valid?
Does it match the hostname?
Is the connection trusted?
Are insecure resources loaded?First test: Access website directly via HTTPS #
Start with the actual HTTPS address:
First, check if the page opens without a security warning.
Afterwards, you should not only test the home page, but also some typical subpages.
For example:
Home page
Subpage
Blog post
Contact page
Shop or product pageA problem can affect only individual pages or resources.
Second test: Call HTTP version #
Then, consciously open the unencrypted version:
http://deine-domain.ch/
On a website that has been completely switched to HTTPS, this should normally become the corresponding HTTPS address.
Also check a subpage:
http://deine-domain.ch/beispiel/
She should not be sent to the home page across the board, but normally to:
also check www and non-www #
Additionally, variants with and without frequently exist www.
For example:
https://example.com/
https://www.example.com/If only one of these variants is used as the primary website, the other should consistently redirect to it.
The same applies to HTTP variants.
A typical configuration can look like this, for example:
http://example.com/
↓
https://www.example.com/
http://www.example.com/
↓
https://www.example.com/
https://example.com/
↓
https://www.example.com/Which variant is used as the primary address is less important than a consistent technical implementation.
Error 1: Certificate has expired #
Certificates have a limited period of validity.
If a certificate is not renewed in time, the browser may display a security warning.
Therefore, you should check the validity dates during the diagnosis:
valid from:
...
valid until:
...If the current date is outside the validity period, the certificate must be renewed or the automatic renewal must be checked.
Why certificates are renewed automatically #
Modern hosting systems frequently automate the issuance and renewal of certificates.
However, automatic renewal can fail if, for example, the domain no longer points correctly to the server or a necessary validation cannot be performed.
Therefore, when a certificate has expired, not only should the certificate be replaced manually, but the cause of the failed renewal should also be investigated.
Error 2: Certificate is not yet valid #
Even a certificate with a validity start date in the future can cause a warning.
In the event of such errors, it should additionally be checked whether the date and time on the affected device or system are set correctly.
An incorrect local clock can cause a certificate that is actually valid to appear from the device's perspective as not yet valid or already expired.
Error 3: Certificate does not match the domain #
A certificate must be valid for the requested hostname.
Suppose you call:
However, the delivered certificate only covers:
www.example.com
ab.
Then there is a hostname mismatch.
The browser cannot verify that the certificate was issued for the hostname actually accessed.
Check Subject Alternative Names #
Modern certificates can be valid for multiple hostnames.
These are typically specified via so-called Subject Alternative Names – or SAN for short.
For example, a certificate could cover the following names:
example.com
www.example.comAnother subdomain like:
shop.example.com
is not automatically included as a result.
Wildcard certificates #
A wildcard certificate can cover multiple subdomains of a specific level.
For example:
*.example.com
can for hostnames like:
shop.example.com
mail.example.com
portal.example.combe used.
The main domain:
example.com
however, is not automatically covered by the wildcard name itself. It may need to be included in the certificate additionally.
Error 4: Incomplete certificate chain #
Browsers do not trust a server certificate in isolation. Intermediate certificates can exist between the website's certificate and a trusted root certificate authority.
Simplified:
Website Certificate
↓
Intermediate CA
↓
Root CAThe server must correctly provide the required certificate chain.
If a necessary intermediate certificate is missing, individual clients may experience issues with trust verification.
Why does a broken certificate chain sometimes still work? #
An already used browser or a specific operating system may already know required intermediate certificates under certain circumstances.
This can cause an incorrect server configuration to appear to work on one device while another device displays a certificate warning.
If HTTPS issues only occur on certain devices, the certificate chain should therefore also be investigated.
Error 5: Mixed Content #
Mixed content occurs when an HTTPS page loads resources over unencrypted HTTP.
For example, the actual page is accessed via:
however, there is a resource in the HTML such as:
<img src="http://example.com/bild.jpg">or:
<script src="http://example.com/script.js"></script>The page itself uses HTTPS, but individual components are requested via HTTP.
Why mixed content is problematic #
HTTPS is intended to establish a secure connection for the delivered content.
If components are loaded via HTTP, this security assumption is not fully met for these resources.
Browsers can therefore block such requests, update them automatically, or issue warnings—depending on the resource type and browser.
Typical causes of mixed content #
After switching from HTTP to HTTPS, old absolute URLs often remain.
For example in:
HTML content
CSS files
theme settings
WordPress database
widgets
page builders
JavaScript
external resources
old image URLsEspecially on older websites, such URLs can be stored in many places.
Find Mixed Content with Browser Developer Tools #
The developer tools of modern browsers are particularly helpful for this diagnosis.
Open the affected page and check in particular the console and the network tab.
In the case of mixed content, you will often find references there to the affected resource.
Search for URLs starting with:
http://
begin, although the page itself via:
https://
was loaded.
Practical Tip: Fix the actual HTTP reference. Simply ignoring a browser warning or disabling security mechanisms locally does not solve the problem for your visitors.
Mixed Content in WordPress #
In WordPress, mixed content occurs particularly often after changing the domain, migrating a website, or a previous HTTP configuration.
First, check whether the WordPress and website addresses are correctly set to HTTPS.
For example:
https://example.comOld HTTP addresses may also be stored directly in content, widgets, theme options, or database fields.
Do not just blindly perform Search & Replace #
A blanket search and replace directly in a WordPress database can be problematic.
WordPress, themes, and plugins can store structured or serialized data. Improper replacement can corrupt this data.
Therefore, use appropriate WordPress tools and create a backup before making extensive changes.
Error 6: Redirect loop after switching to HTTPS #
A faulty HTTPS configuration can create a redirect loop.
For example:
HTTP
↓
HTTPS
↓
HTTP
↓
HTTPS
↓
...The browser stops the redirection after a certain number of steps and reports an error.
The cause can be in various places:
Web server configuration
.htaccess
WordPress
Plugin
Reverse Proxy
CDN
Load BalancerAvoid multiple HTTPS redirects simultaneously #
Problems often arise when multiple layers independently attempt to enforce HTTPS.
For example:
CDN forces HTTPS
Web server forces HTTPS
WordPress plugin forces HTTPS
additional .htaccess rule forces HTTPSThis does not necessarily cause an error, but it makes the configuration unnecessarily complex and makes diagnosis more difficult.
HTTPS should be implemented cleanly and traceably at an appropriate location.
Error 7: Too many redirects #
Even without an infinite loop, an unnecessarily long redirect chain can occur.
For example:
http://example.com/
↓
http://www.example.com/
↓
https://www.example.com/
↓
https://www.example.com/de/If technically feasible, unnecessary intermediate steps should be avoided.
A clean configuration redirects an old variant as directly as possible to the final target URL.
Error 8: HTTPS only works with or without www #
If:
works, but:
generates a certificate warning, it should be checked:
Does the DNS record exist?
Does it point to the correct infrastructure?
Is the hostname included in the certificate?
Is the web server configured for this host?
Is the redirection correct?A certificate can only be provided meaningfully for a hostname if the entire domain and server configuration matches it.
DNS and SSL are related during issuance #
In many automated certificate procedures, it must be proven that the domain or hostname is controlled.
If the domain points to an incorrect infrastructure, automatic issuance or renewal can therefore fail.
In case of problems, you should check the DNS resolution. We explain how this works at Check DNS records.
Do not confuse DNS change and certificate #
After a server change, two separate processes may be involved:
DNS
→ Visitors must reach the
correct server
TLS
→ This server must deliver a
valid certificateA correct certificate on the new server does not help if a visitor still reaches a different server due to their DNS resolution.
Conversely, the domain may already arrive at the new server while a suitable certificate has not yet been installed there.
Error 9: Incorrect certificate is being served #
A server can manage multiple websites and certificates.
In the event of an incorrect virtual host configuration, a certificate from another website may occasionally be served for a domain.
You can recognize this by the fact that the requested hostname does not match the names in the issued certificate.
In this case, it is not the browser that needs to be repaired, but the certificate or web server configuration.
Error 10: Certificate renewed, browser still shows old certificate #
If a certificate has been renewed but the old certificate continues to be served, there can be various causes.
For example:
Web server is still using old certificate file
Service was not reloaded correctly after change
Reverse proxy is serving a different certificate
CDN terminates TLS
DNS points to a different serverTherefore, what is crucial is not only which certificate is stored somewhere on the server, but which certificate is actually delivered when establishing a connection.
consider CDN and reverse proxy #
When using a CDN or reverse proxy, the TLS connection can take place at multiple points.
Simplified:
Visitor
↓ HTTPS
CDN / Proxy
↓ HTTPS
Origin ServerThis allows different certificates to be involved as well.
A valid certificate on the origin server therefore does not automatically mean that the publicly delivered certificate is correct – and vice versa.
Check HTTPS in browser #
You can use the browser for an initial diagnosis.
Check:
Requested URL
Security status
Certificate information
Hostname
Validity period
Issuer
Console
Network requestsIn the event of an error, you should document the exact message instead of merely noting „SSL is not working.“.
The exact error message is crucial #
There is a big difference between the following situations:
Certificate expired
Hostname incorrect
Invalid certificate chain
Mixed content
Redirect loop
DNS points incorrectly
Server unreachableFrom a user's perspective, they can all initially look like an „HTTPS problem,“ but they require completely different solutions.
Check HTTP status code additionally #
HTTPS and HTTP status codes are different layers.
A TLS connection can be established successfully and the website can still respond with:
404 Not Found
500 Internal Server Error
503 Service UnavailableThen the encrypted connection is working, while the application or the requested content has a different issue.
We explain the most important status codes at HTTP status codes explained: 200, 301, 404, 403, and 500.
An HTTP 500 error is not an SSL error #
If the browser successfully establishes an HTTPS connection and the server then responds with 500 Internal Server Error replies, TLS has already successfully done its part.
The cause then typically lies at a later stage.
DNS
↓
TLS successful
↓
HTTP request
↓
Application
↓
500 Internal Server ErrorKeeping these layers cleanly separated saves a lot of time when troubleshooting.
A DNS error is also not automatically an SSL error #
If the domain name cannot be resolved at all, the browser may not yet reach a server with which it could establish a TLS connection.
Even if the website does not appear in the browser, it is initially a DNS or accessibility issue.
HTTPS and website monitoring #
An external HTTPS monitor can regularly check whether a secure connection to the website can be established and an expected response can be received.
Depending on the monitoring system, certificate issues or an impending expiration date can also be monitored.
We explain how such tests generally work at Website Monitoring: Monitor Availability and Outages.
Why certificate monitoring makes sense #
Automatic certificate renewal significantly reduces administrative overhead. Nevertheless, a renewal can fail due to a technical glitch.
An additional external check can therefore help to detect an unexpectedly upcoming expiration date in good time.
Monitoring does not, however, replace fixing the cause if the automatic renewal is actually malfunctioning.
HTTPS and Google #
For search engines, the signals of an HTTPS website should be consistent.
If HTTPS is the preferred variant, among other things:
Internal links
Redirects
Canonical URLs
XML sitemap
Public website URLsconsistently point to the HTTPS version.
The XML sitemap should contain the desired HTTPS URLs accordingly. You can find out more at XML Sitemap: What it does and how to submit it to Google.
Do not point canonical to HTTP #
When the website has been completely switched to HTTPS, an HTTPS page should normally not simultaneously designate an HTTP version as the preferred URL via its canonical element.
Such a configuration produces contradictory technical signals.
Simplified, the image should look like this:
HTTP
↓ 301
HTTPS
↓
Canonical → HTTPS
↓
Sitemap → HTTPS
↓
Internal links → HTTPSCheck after an HTTP to HTTPS migration #
When a website has been newly migrated to HTTPS, you should not only check whether the homepage has a certificate.
Check systematically:
Is the HTTPS home page reachable?
HTTP → HTTPS?
Subpages correctly redirected?
www / non-www correct?
Certificate valid for all required hostnames?
Mixed content present?
Internal links to HTTPS?
Canonical set to HTTPS?
Sitemap contains HTTPS?
Check important pages in Search Console?Check HTTPS version in Google Search Console #
With the Google Search Console URL inspection tool, you can check which URL Google knows and how a specific page is processed.
When dealing with indexing issues, however, you should not view HTTPS in isolation. Crawlability, HTTP status, canonicals, sitemaps, and indexing directives also play a role.
You can find the systematic procedure under Google is not indexing my website: Check causes.
Don't over dramatize Mixed Content and SEO #
Mixed content should be fixed, primarily for security, functionality, and quality reasons.
However, it is hardly helpful to label every HTTPS error across the board as an „SEO disaster“.
The actual impact depends on which error is present and which resources or URLs are affected.
Technical problems should therefore be fixed based on their real cause and not because of exaggerated SEO promises.
HTTPS does not automatically make a website secure #
This difference is particularly important.
HTTPS protects data transmission between client and server.
However, it does not automatically protect a website against:
insecure passwords
outdated plugins
malware
SQL injection
stolen credentials
insecure user accounts
file manipulation
application errorsImportant: A valid SSL certificate means that an encrypted connection can be established to the verified hostname. It is not a general security certificate for the entire website.
Even a hacked website can have a valid certificate #
A compromised web server can still deliver a completely valid TLS certificate.
The browser can then establish a technically encrypted connection, even though the website itself has been tampered with.
HTTPS and application security must therefore be considered separately.
HTTPS does not protect against a fake website #
A valid certificate primarily confirms the connection to the hostname contained in the certificate. It does not confirm that a company, offer, or content is automatically trustworthy.
Fraudulent websites can also use HTTPS.
Visitors should therefore continue to pay attention to the actual domain and context of a website.
What to do in case of a browser warning? #
If your browser warns you about a certificate or HTTPS connection, you should not simply bypass the warning permanently.
For your own website, the following diagnosis is recommended:
note exact error message
↓
check hostname
↓
view certificate
↓
check validity period
↓
check SAN / hostname
↓
check certificate chain
↓
check DNS resolution
↓
consider proxy / CDN
↓
check server configurationDon't prematurely blame the browser cache #
When troubleshooting HTTPS issues, clearing the browser cache is often recommended first.
This can be helpful in certain situations, but should not replace an actual diagnosis.
If the publicly served certificate has expired or is issued for the wrong hostname, clearing the regular website cache will not fix the issue.
Check problem on multiple devices #
If only a single device shows a certificate warning while other current devices work without any issues, you should also investigate the local environment.
Possible factors are:
incorrect system time
outdated operating system
outdated browser
local proxy
antivirus software
corporate network
local certificate storeIf, on the other hand, numerous independent devices receive the same warning, it points more strongly to a server- or certificate-side issue.
Error only in one network #
If HTTPS works over mobile data but not in a corporate or home network, additional local network components may be involved.
For example:
Proxy
Firewall
DNS Resolver
TLS Inspection
VPN
Local filterSuch a test helps to narrow down the cause spatially.
Check system time #
Certificates have a defined period of validity.
If a device's date or time is significantly incorrect, a browser may evaluate a valid certificate as invalid.
With unexplained certificate warnings on just one device, checking the system time is therefore one of the simple first checks.
Errors after a website migration #
After a hosting or server change, HTTPS issues can arise if individual components of the transition do not yet match.
Check in particular:
DNS pointing to new server?
Certificate present on new server?
All required hostnames included?
HTTP redirects correct?
Old HTTP URLs in website?
CDN / proxy updated?
Sitemap and canonical correct?DNS changes can also take time until different resolvers use the new state. We explain more about this under DNS Propagation explained.
Error after changing the domain #
If a website by:
on:
relocates, the new domain requires a suitable certificate.
The old domain should also remain technically accessible during the migration so that redirects to the new domain can function.
A certificate error on the old HTTPS domain can hit visitors before an HTTP redirect can even be processed.
Why HTTPS must work before a redirection #
This is a frequently overlooked technical point.
For example, a visitor accesses:
Before the web server sends a response such as:
301 Moved Permanently
can send, the TLS connection to the old domain must first be established.
If their certificate is invalid, the browser may display a security warning beforehand.
Practical Tip: During a domain migration, do not let the certificate of the old HTTPS domain expire prematurely. The old URLs must still be securely reachable so that their redirects can be processed reliably.
Do not confuse SSL certificate and email #
A certificate for the website at:
is not automatically the entire TLS configuration of all other services on the domain.
Email services like IMAP or SMTP can use different hostnames and their own TLS connections.
Therefore, a working HTTPS certificate of the website does not automatically prove that all e-mail services are correctly configured.
Systematically troubleshoot HTTPS errors #
A good diagnosis follows a set sequence.
Access domain
↓
DNS working?
↓
Server reachable?
↓
TLS connection possible?
↓
Certificate valid?
↓
Hostname correct?
↓
Certificate chain correct?
↓
HTTP response correct?
↓
Redirects correct?
↓
Mixed content?
↓
Application working?This prevents you from looking for problems at the wrong level.
Typical SSL and HTTPS errors #
Certificate expired
Certificate not yet valid
Hostname does not match
www not covered
Subdomain not covered
Certificate chain incomplete
Wrong certificate served
Mixed Content
HTTP does not redirect to HTTPS
Redirect loop
Unnecessary redirect chain
DNS points to wrong server
CDN serves different certificate
Old HTTP URLs after migration
Canonical points to HTTP
Sitemap contains old HTTP URLs
Old domain loses certificate before migration is completeChecklist: Check SSL and HTTPS #
Open https:// directly
↓
Browser warning present?
↓
Open certificate
↓
Check validity period
↓
Check hostname / SAN
↓
Check certificate chain
↓
Open http://
↓
Check redirect to HTTPS
↓
Check www and non-www
↓
Check important subpages
↓
Open browser console
↓
Search for mixed content
↓
Check HTTP status
↓
Check DNS resolution
↓
Consider CDN / proxy
↓
Check internal links
↓
Check canonical
↓
Check XML sitemap
↓
Control external monitoringSummary #
A functioning HTTPS setup consists of more than just an installed SSL certificate. The domain, DNS, certificate, web server, redirects, and the resources loaded by the website must all work together.
In the event of a certificate error, you should first check whether the certificate is valid in terms of time and matches the requested hostname. Subsequently, the certificate chain, DNS resolution, server configuration, and, if applicable, CDN or reverse proxy can be investigated.
Mixed content is a different issue: here HTTPS works in principle, but the secure page tries to load individual resources via HTTP. Such references should be corrected at their original source.
On a website that has been completely switched to HTTPS, HTTP variants should cleanly redirect to HTTPS. Internal links, canonical URLs, and XML sitemaps should also consistently use the desired HTTPS addresses.
Special care is required during domain and server migrations. The old domain also continues to require a valid certificate during an HTTPS migration if visitors access secure old URLs and are subsequently redirected.
HTTPS must also not be confused with complete website security. An encrypted connection protects data transmission, but it does not prevent security vulnerabilities in WordPress, plugins, applications, or user accounts.
Therefore, in the case of HTTPS problems, the exact error message is more important than the blanket statement „SSL doesn't work.“ Anyone who views DNS, TLS, HTTP, and the application as separate layers will find the actual cause much faster.
