Note: The SSL certificates that we offer are compatible with our service and all modern web browsers. The following information is important if you are purchasing an SSL certificate from a third party vendor.
Some SSL certificates can work properly in Internet Explorer but create errors or warnings in Netscape, Firefox and other browsers (or vice versa). Why are some certificates incompatible with some browsers?
Every web browser checks a list of "Trusted Root Certificates" in order to establish a secure connection. These lists are generally the same between the different browsers, but discrepancies can occur (one browser lists a Trusted Root certificate or intermediate certificate while another browser does not). Additionally, all browsers do not handle certificates in the same way.
An SSL Certificate will only be recognized by a browser if the root certificate the SSL certificate uses to establish "trust" is listed in the "Trusted Root Certificates" of the browser. If that chain of trust cannot be established, the visitor will see a warning message and may be unable to establish a secure connection to your site.
Important note: We trust the certificate authorities listed on the Microsoft Root Certificate Program Members page. The root certificates from these authorities are already installed on the server. Other third-party root certificates are NOT supported. Intermediate certificates and certificate chains
To understand why SSL errors may occur it is necessary to have a general overview of how SSL certificates work.
SSL certificates are issued by several companies (referred to as "certification authorities") at different price levels. Typically the most costly certificates are what is known as "single root certificates." Less costly certificates are often "chained root certificates," which consist of one or more "intermediate certificates" that point to a root certificate.
Single root certificate
A single root certificate is a certificate that is issued for your domain which "trusts" the issuing authority's root certificate. So for example, if you purchased a single root SSL certificate from the ABC company, your certificate would trust the root certificate named ABCRootCertificate in your browser's Trusted Root certificate list.
The "chain of trust" looks like this: ABCCertificateForYourDomain -> ABCRootCertificate
"Chained root" certificate
A chained root certificate is a certificate that is issued for your domain which "trusts" one or more "intermediate" certificates, which in turn trust a root certificate (which may or may not be issued by the same certificate authority). So for example, if you purchased a chained SSL certificate from the XYZ company, your certificate would trust the intermediate certificate, which in turn trusts a root certificate in your browser's Trusted Root certificate list.
XYZCertificateForYourDomain -> XYZIntermediateCert1 -> ABCRootCertificate
As you can see, a single root certificate is a direct path to the root certificate, and a chained root certificate is a less direct path. We support third-party intermediate certificates, but they must be from a trusted root certificate authority. The most common intermediate certificates are already installed on the server. We will contact you if we need a copy of the intermediate certificate.
The problem with certificate names
Some certification authorities have issued their own root certificates which conflict (or will in the future) with earlier intermediate certificates. For example, they may have issued a chained root SSL certificate which has a chain of trust like this:
XYZCertificateForYourDomain -> XYZIntermediateCert1 -> XYZIntermediateCert2 -> ABCRootCertificate
In this example the XYZIntermediateCert1 certificate trusts XYZIntermediateCert2, which in turn trusts the ABC root certificate. So far so good.
But let's say the XYZ company decides to issue their own root certificate named XYZIntermediateCert2, and has XYZIntermediateCert2 added to the lists of Trusted Root certificates used by the browsers. This is where the problems arise. If, for example, your older XYZ company certificate still uses ABCRootCertificate as the root:
XYZCertificateForYourDomain -> XYZIntermediateCert1 -> XYZIntermediateCert2 -> ABCRootCertificate
But the browser now recognizes the new XYZIntermediateCert2 as a root certificate, so in the chain of trust, the browser will now stop at XYZIntermediateCert2, since that is listed as a Trusted Root certificate.
SSLCertificateForYourDomain -> XYZIntermediateCert1 -> XYZIntermediateCert2
Which breaks your certificate, because it still considers XYZIntermediateCert2 to be an intermediate certificate, not a root. But as far as the browser is concerned, XYZIntermediateCert2 is now a root certificate, so it stops there and will not look further for the root required by your certificate.
Would a certification authority give a new root the same name as a previous intermediate certificate?
Unfortunately, some, such as Comodo and GoDaddy, already have. GoDaddy recommends disabling their new root certificate, since it is designated for "future use." We have done so, but as soon as they begin to issue certificates that use the new root, we will have to enable it on the server, which will break all old chained root certificates that use the new root as an intermediate certificate.
GoDaddy has indicated that they will contact all certificate holders that may be affected by the change when it occurs and provide a solution, but we still expect that some of our users who have purchased SSL certificates from GoDaddy will experience problems when the GoDaddy root certificate is activated.
In general, we recommend the use of "single root" certificates, such as those issued by:
Looking for added security? SiteLock scans your website to detect hacking, and SiteLock TrueShield provides a Web Application Firewall to block online threats.
Protect your site today.