SSL certificates are used on millions of websites to provide security and confidentiality for online transactions. However, there are a few problems that can occur with their deployment that cause error messages to be shown to website visitors. This page aims to provide an overview of the most common SSL errors along with suggestions on how to fix them.
What is an SSL connection error?
SSL connection errors occur when you are trying to connect to an SSL-enabled website and your browser (client) is unable to make a secure connection to the website's server. Depending on the cause of the connection error, internet browsers will usually display a warning messages such as "This Connection is Untrusted", "The site's security certificate is not trusted" or "Your Connection is not private".
The SSL certificate for this website is not trusted
An internet browser will state that a website certificate is untrusted if that certificate has not been signed by a trusted Certificate Authority. In order for a browser to accept a certificate, it must be able to link it to a 'trusted root certificate'.
Trusted root certificates are embedded into popular browsers such as Internet Explorer, Firefox, Chrome. These root certificates are used as trust 'anchors' to verify the legitimacy of all website certificates that the browser encounters. If a browser encounters a certificate that is not signed by one of these roots, then it will state it is untrusted and visitors will see an error message like the one above. Most trusted root certificates in a browser are owned by an accredited Certificate Authority (CA). When a CA signs the certificate of a website, it is effectively 'linking' that website's certificate to one of their trusted roots in the browser certificate store. For security reasons, most CA's do not sign end-entity/website certificates directly from the root, but will instead use an 'intermediate certificate' to create a 'chain of trust' to the root. In this system, the root certificate will sign the intermediate and the intermediate is used to sign the certificates of individual websites.
'Untrusted' errors, therefore, are usually caused for one of two reasons:
- Site uses a self-signed certificate
In many cases, this is because the website is using what is known as a 'Self Signed Certificate'. As the name suggests, a self-signed certificate is one that the website owner has generated and signed for themselves using their webserver software. Therefore, the certificate is not associated with any 'trusted root' in the browser's certificate store and the browser will display an 'untrusted' error.
Self-signed certificates do have their advantages. They are free to generate and are fine for use on intranet and development servers where the only people expected to trust the server are internal personnel such as company employees. However, they should never be deployed on commercial websites that the general public are expected to trust. - Intermediate certificate(s) not installed
Another potential reason for the 'Untrusted' error is because the website administrator has not correctly installed all intermediate certificates on their webserver. The following example provides a better illustration of this issue:
The diagram above shows the certificate for www.instantssl.com. The 'Certification Path' tab shows the chain of trust that the internet browser will use to verify the certificate. The trusted root certificate has signed the Intermediate certificate which has in turn signed the Website certificate.
When a visitor makes a connection to www.instantssl.com, the webserver should present both the website certificate AND the intermediate certificate to the visitor's browser. The browser will then be able to check all certificates in the chain back to the root certificate. Most certificate authorities will send a bundle file to the website owner which contains all required intermediates along with the end-entity/website certificate. However, if the webserver admin doesn't install all intermediates, then users will see a 'certificate not trusted' message. Sometimes this omission may be due to the complexity of certificate installation on a particular webserver. For this reason, instantssl provide a complete set of installation instructions for all popular webserver types.
Certificate Name 'Mismatch' error
The 'certificate name mismatch' error occurs when the domain listed on the SSL certificate presented by the server does not match the domain that the browser is connected to. For a HTTPS session to commence, the domain on the certificate must exactly match the domain in the browser address bar.
There are a few reasons that this could happen:
- The website/host was accessed using an internal hostname or an IP address, but the certificate was issued only to the public Fully Qualified Domain Name (e.g. www.domain.com). Accessing the host using an internal name or IP might well get you to the same website, but if the certificate only contains the FQDN it may cause a mismatch error.
- The certificate was issued to domain.com, but www.domain.com was typed into the browser ('www' is actually a sub-domain of domain.com). This error can still occur but is becoming less common because most major CAs, including Sectigo, issue single domain certificates that cover both domain.com and www.domain.com. However, if you encounter this error, it is still worth considering this as a potential cause. Incidentally, the use of a wildcard certificate will also prevent this problem as any and all sub-domains of domain.com will be covered automatically.
- The name mismatch error can also occur when multiple websites are hosted on the same IP address. This is often the case in many shared hosting environments. Under a normal HTTP connection, the browser will tell the server which domain it wishes to connect in what is known as the host header. However, when a HTTPS connection is made, the SSL handshake means the browser requests a certificate from the server before it presents the host header. As a result, the server does not have the information required to decide which certificate to send and will often present the wrong certificate. If there is only one website and one certificate on an IP, then this shouldn't be a problem. However, if there are multiple websites on the same IP, the server may provide a certificate for the wrong domain. This issue can be averted by the use of a Multi-Domain Certificate, which allows website owners to add all websites and hostnames to the Subject Alternative Name (SAN) field of the certificate.
Mixed content Error
For a secure, HTTPS connection to be established, every item on the page must be served from a secure source. This means all embedded images, videos, flash movies, iframes and Java scripts must be served from a secure location. If any items are not, then website visitors will see an error message similar to this:
If the visitor chooses 'Yes', then all items will be displayed BUT the connection will revert to insecure HTTP. If the visitor chooses 'No', then only the secure items will be displayed. This could mean that certain images and videos are not shown or that the page will fail to execute important scripts. Either way, this is bad signal to send to your website visitors. This is arguably the most widespread of all SSL errors, but is also one of the easiest for an admin to fix.
- Don't call any insecure content over HTTP or port 80. Change all references and links from HTTP to HTTPS. For example, <img src="
" alt="" >. You will need to make sure you have SSL set up on the source location for this to work most effectively. If you use a sub-domain to host your website elements, then a wildcard certificate can assist in this effort. - Use relative links on your website instead of absolute links. For example, instead of src=http://mydomain.com/my-script.js, use scr=/my-script.js. Then, if your main page is accessed over HTTPS, the browser will also load /my-script.js over HTTPS. This technique is also very useful if your page references external content that is explicitly server over HTTP (YouTube or Google Analytics, for example).
- Deploy SSL across your entire site. This will ensure much better security for your visitors and, because Google is awarding higher search ranking to secure pages, it may also improve your SEO efforts. Please note that doing so may mean you effectively have two copies of your content, so you will need to tell the search engine which version is authoritative. To do this:
- Tell the search engine that the HTTPS version is authoritative by (i) Updating link <rel="canonical"> to point to the HTTPS version (ii) Updating the XML sitemap to refer to the HTTPS version of your content. Making these changes means the search engine will index the SSL version of your site and present this version in the search engine results.
- Make sure robots.txt is available over HTTPS.
- Redirect all HTTP requests to the HTTPS version with a permanent 301 redirect. This means your search engine page rank will be transferred to the HTTPS version.
- Update webmaster tools to reference the HTTPS version of your site instead of HTTP.