Fix SSL Certificate Connection Errors

Used by millions of web sites across the globe, SSL certificates provide security and confidentiality for internet users. But with so many deployments, errors can sometimes occur.

What is an SSL Connection Error?

SSL connection errors occur when your browser is unable to securely connect to a web site's server. Depending on the cause of the connection error, internet browsers will usually display a warning message, 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 web site is not trusted.

An internet browser will tell you a web site is untrusted if its SSL certificate has not been signed by a trusted Certificate Authority. For a browser to accept a SSL certificate, it must be able to link it to a trusted root certificate, which are used to verify the legitimacy of web site certificates.

Most trusted root certificates are owned by an accredited Certificate Authority (CA). When a CA signs the SSL certificate of a web site, it links that web site's certificate to one of its trusted roots. For security reasons, most CA's do not sign end-entity/web site SSL certificates directly from the root but instead use an intermediate certificate to create a chain of trust with the root, so the root can sign an intermediate that can then sign individual SSL certificates.

Untrusted errors are usually caused by the following issues:

Site uses a self-signed SSL certificate.

A self-signed SSL certificate is generated by the web site owner instead of a CA and is therefore not associated with any trusted root in the browser’s certificate store, giving the end user an “untrusted” error.

While self-signed SSL certificates are free and work well on intranet and development servers — where only internal personnel need to use them — self-signed certificates should never be deployed on commercial web sites.

Intermediate certificate(s) not installed

Another potential reason for the 'Untrusted' error is because the web site administrator has not correctly installed all intermediate SSL certificates on their webserver.

When a visitor connects to your site, the webserver should present both the web site SSL certificate and any intermediate certificates to the visitor's browser, allowing it to check all certificates in the chain back to the root. While most certificate authorities will send a bundle that contains all required intermediates and end-entity/website SSL certificates, if the webserver admin doesn't install all intermediates, users will see a “certificate not trusted” message.

To avoid this problem, check out Sectigo’s complete set of installation instructions.

Certificate Name Mismatch Error

The “certificate name mismatch” error occurs when the domain listed on the SSL certificate does not match the domain that the browser is connecting to. For an HTTPS session to commence, the domain on the SSL certificate must exactly match the domain in the browser address bar.

There are a few reasons this error could occur:

  • The web site was accessed using an internal hostname or an IP address, but the SSL certificate was issued only to the public Fully Qualified Domain Name (e.g. www.domain.com), causing a mismatch error.
  • The SSL certificate was issued to domain.com, but www.domain.com was typed into the browser (“www” is actually a sub-domain of domain.com). While this error can still occur, it’s becoming less common as most major CAs — including Sectigo —issue single domain SSL certificates that cover both domain.com and www.domain.com. To prevent this on your site, use a wildcard SSL certificate to automatically cover all sub-domains.
  • The name mismatch error can also occur when multiple web sites are hosted on the same IP address. Under a normal HTTP connection, the browser will tell the server which domain it wishes to connect to. However, when an HTTPS connection is made to an IP address with multiple sites, the browser requests an SSL certificate from the server before it knows which domain to connect to, causing the server to present the wrong certificate. This issue can be neutralized with a Multi-domain certificate, which allows web site owners to add all web sites and hostnames to the Subject Alternative Name (SAN) field of the SSL certificate.

Mixed Content Error

For an HTTPS connection to be established, every item on the page must be served from secure sources — from images and videos to iframes and Java scripts.

If any of the embedded items are not secure, users can choose to either view the site in the unsecure HTTP format or view only those items that are secure — neither of which instills trust in your customers. While this is the most widespread SSL error, it’s very easy to fix.

  • Change all references and links from HTTP to HTTPS. For example, <img src="" alt="" >. You will need to make sure you have the SSL set up on the source location. If you use a sub-domain to host your web site elements, a wildcard SSL certificate will work best.
  • Use relative links on your web site 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 served over HTTP (YouTube or Google Analytics, for example).
  • Deploy SSL across your entire site to ensure better security for your visitors and improved SEO performance, due to Google awarding higher search ranking to secure pages.
    • 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.
    • 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 it in the search 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.