Skip to McMaster Navigation Skip to Site Navigation Skip to main content
McMaster logo

Office of the AVP & CTO

INFORMATION TECHNOLOGY SECURITY

Issues With SSL Certificates

Resolving Problems With Intermediate Certificates

SSL certificates are issued by companies referred to as “certificate authorities”. Our SSL Certificate Provider, SECTIGO (previously known as COMODO) is one such company. As a result of their recent change of company names, SECTIGO issued a new set of intermediate certificates to ensure 100% trust when using their certificates. This has caused some confusion in some cases, due to certificates that have been installed without the provided complete suite of certificates on to their servers. This in turn caused some trust issues as some browsers, Firefox in particular, failed to recognize the newly deployed certificate as trustworthy due to “intermediate certificate” issues.

Every time a browser encounters an SSL certificate, it checks its own list of Trusted Root Certificates in order to establish a secure connection. These lists are generally the same across different browsers, but sometimes, discrepancies can occur. A typical issue arises when for example one browser lists a Trusted Root certificate or intermediate certificate while another browser might not. Additionally, browsers do not handle certificates in the same way. In this brief article we try to explain how issues might arise and how to address them.

Typically, certificates vary from what are known as single root certificates, usually expensive, to less costly certificates known as “chained root certificates”. Our attention will focus on the latter kind. Chained root certificates normally consist of an end-user certificate and one or more intermediate certificates that point to a root certificate. From the browser’s perspective, an SSL Certificate will only be recognized as trustworthy if the root certificate the end-user certificate refers to in order to establish “trust” is listed in the “Trusted Root Certificates” of the browser. If that chain of trust cannot be established or completed, the visitor will see a warning message and may be unable to establish a secure connection to the site.

The key factor to keep in mind when dealing with “chained” certificates is hierarchy. Certificates that are chained obey a hierarchy that has been established to resolve and discover the ultimate source of trust: the root certificate. If the root certificate is not discovered, the end-user certificate is untrustworthy. Separate from that, intermediate certificates by themselves are useless unless they are positioned in such a way that they can be used to discover and resolve the chain of trust.

The diagram below shows how the chain tipically looks in a Windows system:

certificate window screenshot

A number of factors can come into play when browsers are attempting to resolve the chain and establish trust:

  • the type of browser
  • the operating system and browser version level and its local SSL repository status
  • the server’s SSL certificate deployment scenario
  • the age of the end-user and intermediate certificates

If any of the above items are off or not properly aligned, the user experience might be affected.

To counter for this potential problem, resulting primarily from the recent name change, Sectigo issued the following new set of intermediate certificates in December 2018:

New primary intermediate:

Subject: CN=Sectigo RSA Organization Validation Secure Server CA;
Serial Number: 137d539caa7c31a9a433701968847a8d;
expiry Date: ?Tuesday, ?December ?31, ?2030 6:59:59 PM;
Thumbprint: 40cef3046c916ed7ae557f60e76842828b51de53

New secondary intermediate:

Subject: CN=USERTrust RSA Certification Authority;
Serial Number: 13ea28705bf4eced0c36630980614336;
Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM;
Thumbprint: eab040689a0d805b5d6fd654fc168cff00b78be3

Compare the above with the old set of intermediate certificates previously released by Comodo:

Old primary intermediate:

Subject: CN=COMODO RSA Organization Validation Secure Server CA;
Serial Number: 36825e7fb5a481937ef6d1736bb93ca6;
Expiry Date: ?Sunday, ?February ?11, ?2029 6:59:59 PM;
Thumbprint: 104c63d2546b8021dd105e9fba5a8d78169f6b32

Old secondary intermediate:

Subject: CN=COMODO RSA Certification Authority;
Serial Number: 2766ee56eb49f38eabd770a2fc84de22;
Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM;
Thumbprint: f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0

Both the old and the new set still point to the following root certificate as shown in the diagram below:

Root certificate:

Subject: CN=AddTrust External CA Root;
Serial Number: 1;
Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM;
Thumbprint: 02faf3e291435468607857694df5e45b68851868

flowchart diagram

Comparing both sets show that they have different primary and secondary intermediate, but the same root certificate. The new set now shows the company name as SECTIGO. As OS and browsers get updated, they should receive the new sets of intermediate certificates but until that happens, the resolving of the chain and discovery of the root must be accomplished by having the web server to provide both the end-user certificate and the intermediate certificates. The root certificate is much older and it exists on 99% of all local OS and browser SSL repositories. Systems receive updates in a flexible manner depending on the service providing these updates and the owner of the system’s diligence in staying updated. Some systems will not get updated for various reasons (i.e., users neglecting to update or unable to reach a source of updates). Issues resulting from these scenarios should be treated on a case by case basis and will depend on the condition of the client system at the time the issue is occurring.

Notice also that, on the new set, the expiry dates of the intermediates and root are sometime in the year 2020. This will require that Sectigo issue new intermediate certificates for all browsers globally sometime in the near future or resort to some other mechanism to resolve trust most likely using another intermediate certificate that can also be found on 99% of systems:

Subject: CN=COMODO RSA Certification Authority;
Serial Number: 4caaf9cadb636fe01ff74ed85b03869d;
Expiry Date: ?Monday, ?January ?18, ?2038 6:59:59 PM;
Thumbprint: afe5d244a8d1194230ff479fe2f897bbcd7a8cb4

This certificate has the same purpose as the old intermediate that was previously distributed by Comodo but with a much later expiration date and could still be used to resolve chains in future deployments.

Caching problems

It has been observed that when client systems experience SSL trust problems, particularly when opening browsing sessions, the system might keep and use a cache of visited pages despite the SSL issue having been resolved on the server side, giving the impression after re-visiting the web site that there is still a problem when in fact the issue has been resolved. To ensure this does not happen, we recommend asking clients to browse using the “New Private Window” option. This method will ensure that no old cache, cookies or pre-existing settings are used when visiting a web site. If the SSL issue has indeed been resolved on the server side, this method of browsing will make sure that a fresh session is started and will show the updated status of the SSL certificate.

In Summary

Sectigo SSL certificates rely on a chain to establish trust and discover the root Certificate Authority. In order to prevent issues stemming from browsers having different levels and versions of the intermediate certificates in their local repositories, servers using SSL certificates must contain and provide the proper intermediate certificates to assist client browsers in trying to establish trust by properly resolving the SSL chain. Intermediate certificates are deployed in the same manner as regular end-user certificates and the method depends on the type of web server technology. When requesting SSL certificates, administrators must carefully specify the type of certificate and the web server technology it will be deployed on. following the tips provided above will ensure that Sectigo provides the proper set of certificates for the indicated type of server.

Keep in mind that you can secure your website using SSL encryption at no cost to you or your department. McMaster University is now offering SSL, Code signing and client certificates from Sectigo to users at no charge. You can request an SSL certificate by contacting the IT Security team at c-it-security@mcmaster.ca or by submitting a UTS help desk ticket. As well, IT administrators who are interested in managing their group’s certificates can request to be added to the Sectigo administrator console by getting in touch with the IT Security team.

You can read more on the process of obtaining an SSL certificate by visiting Comodo SSL Certificates


Adapted from:
SSL certificates, intermediate certificates and browser compatibility
Understanding An SSL Certificate Chain