[Skip navigation links]

Deprecation of SHA1 certificates

Background

Microsoft and many other vendors are phasing out support for SHA1 certificates and some vendors have published timelines when these certificates will no longer be trusted on their platforms or by their applications.

Therefore, it is recommended that you review your affected Comodo (and other) SHA1 certificates and prepare a plan to replace those certificates in accordance with the key dates identified by vendors, when these certificates will no longer be trusted.

Summary 

  1. For security reasons, all SHA1 certificates should be replaced as soon as possible.  
  2. All SHA1 certificates should be replaced by the end of 2015 to avoid significant certificate errors in browsers.
  3. Many SHA1 certificates should be replaced now to avoid serious browser warnings, such as neutral, lacking in security and affirmatively insecure.
  4. If there are any concerns about whether the SHA2 certificates will be compatible with your devices, operating systems and applications, please check the section on Compatibility below.
  5. For further information please see the summary prepared by QuoVadis.

QuoVadis TrustLink

QuoVadis, by default, issues SHA2 certificates via TrustLink that are signed by an Issuing Certificate Authority (intermediate) certificate that uses SHA2. While these certificates may chain up to a SHA1 root certificate, they are not affected by these changes and are automatically trusted because TLS clients trust them by their identity, rather than by the signature of the hash. 

QuoVadis grid certificates (host and end-user), and SSL certificates are now also SHA2.  See information about QV intermediate and root certificates.

Comodo Certificate Service Manager

By contrast, all Comodo certificates that are signed with the AusCERT sub-CA intermediate certificates and Comodo intermediate certificates use the SHA1 signature algorithm. All SSL, S/MIME and code-signing certificates for AusCERT Server CA (SSL); AusCERT SGC Server CA (SSL); AusCERT Client CA; and AusCERT Code Signing CA are affected.

Some EV-SSL certificates issued by Comodo may also be affected. Check the “Signature hash algorithm” in the end certificate to see if it uses SHA1.

SSL certificate with SHA1 SSL certificate with SHA2
Example of SHA1 certificate Example of SHA2 certficate

 

Compatibility issues

Most organisations won’t experience compatibility issues but older systems such as those running MS Win XP (SP2) or older, or outdated browsers may not support SHA2 encryption.  See https://support.quovadisglobal.com/KB/a417/what-supports-sha-256-certificates.aspx?KBSearchID=28102 and SHA256 Support List for guidance.

Which certificates should be replaced and when?

Due to the insecure nature of the SHA1 algorithm, it is good practice to replace SHA1 certificates with SHA2 certificates as soon as possible. (Check SHA2 compatibility first). But for practical reasons, the process will generally need to be staggered to occur within the critical dates promoted by Microsoft and other vendors.  

Your plan should replace SHA1 SSL certificates in the following order:

  1. certificates with an expiry date of 1 January 2017 or later.
  2. certificates with an expiry date between 1 June 2016 and 31 December 2016, inclusive.
  3. certificates with an expiry date before 1 June 2016.

SSL certificates

To be trusted by Microsoft applications/platforms, then all SHA1 SSL certificates which are due to expire on or after 1 January 2017 should be replaced and installed before 1 January 2017. Please note that these dates could be brought forward.

Mozilla has stated that "after January 1, 2016, we plan to show the “Untrusted Connection” error whenever a newly issued SHA-1 certificate is encountered in Firefox. After January 1, 2017, we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox."

Google has developed its own timeline for Chrome (for which the current version is 37).

• From version 39, (26 September 2014), all certificates which are due to expire on or after 1 Jan 2017, which include a SHA1 signature algorithm will be treated as “secure but with minor errors”.

• From version 40 (7 November 2014), all certificates which are due to expire between 1 June 2016 to 31 December 2016 (inclusive), which include a SHA1 signature algorithm will be treated as “secure but with minor errors”; and all certificates which are due to expire on or after 1 January 2017 and which include a SHA1 signature algorithm will be treated as “neutral, lacking security”;

• From version 41 (Q1 2015), all certificates which are due to expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA1 based signature as part of the certificate chain, will be treated as “secure, but with minor errors”; and sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA1 based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Sub-resources from such domains will be treated as “active mixed content”.

Before 1 January 2017

To avoid untrusted certificate warnings on Microsoft platforms, replace all SSL certificates with expiry dates on or after 1 January 2017.

Chrome SHA1 deprecation schedule

Chrome version Approximate release date SHA1 SSL expires Jan-May 2016 SHA1 SSL expires Jun-Dec 2016 SHA1 SSL expires after 2016 Browser warning
39 November 2014 No change No change Yellow triangle (secure with minor errors). Displays the warning: The site is using security settings that may prevent future versions of Chrome from being able to safely access it. Chrome minor errors
40 December 2014 No change Yellow triangle. Displays the warning: The site is using security settings that may prevent future versions of Chrome from being able to safely access it. No lock icon (neutral, lacking security) Chrome lacking security
41 January 2015 Yellow triangle (secure with minor errors). Displays the warning: The site is using security settings that may prevent future versions of Chrome from being able to safely access it. Yellow triangle (secure with minor errors).  Displays the warning: The site is using security settings that may prevent future versions of Chrome from being able to safely access it.

Red X (affirmatively insecure).

Based on Google's SSL SHA1 yellow triangle warning, it is possible that Google Chrome users will no longer be able to navigate to sites with this certificate error.

Chrome insecure

Before 11 February 2015*

To avoid Google Chrome users receiving “affirmatively insecure” browser warnings, you should replace SSL certificates with expiry dates on or after 1 Jan 2017.

Before 18 December 2014*

To avoid Google Chrome users receiving “neutral, lacking security” browser warnings, you should replace SSL certificates with expiry dates on or after 1 Jan 2017.

To avoid Google Chrome users receiving “secure but with minor errors” browser warnings, you should replace SSL certificates with expiry dates ranging from 1 June 2016 to 31 December 2016 inclusive.

Before 6 November 2014*

To avoid Google Chrome users receiving “secure but with minor errors” browser warnings, you should replace SSL certificates with expiry dates on or after 1 Jan 2017.

Important note*

Please note that these dates with an asterisk are indicative only and are the estimated date that Google will "release stable versions of Chrome".  They have been calculated by adding 6 weeks to each of the version "Branch Point" dates published by Google.   Google could, of course, release the stable version before or after this time.

Code-signing certificates

To be trusted by Microsoft applications/platforms, then all SHA1 code signing certificates should be replaced before 1 January 2016.  Digital signatures created from SHA-1 code signing certificates that were timestamped before 1 January 2016 will continue to be trusted on Windows platforms but digital signatures without a timestamp will not be trusted.  It is always good practice to timestamp digital signatures when signing code.

Personal (S/MIME) certificates

We are not aware of information relating to when SHA1 personal certificates will become obsolete; but they will be in due course. It is recommended to replace these as soon as possible or before 1 January 2016 (as with code-signing certificates).

Find affected SHA1 certificates for your organisation

All Comodo certificates issued through the CSM are SHA1. For Comodo certificates which were issued via the CSM, https://cert-manager.com/customer/auscert log in and download separate reports for your organisation for SSL, code-signing and sort by the expiry dates.

Replace then revoke

When replacing your SHA1 certificate with a SHA2 certificate, please generate a new CSR and key pair, rather than reusing your old keys.  As you replace your SHA1 certificates with SHA2 certificates, don't forget to revoke the old certificates.

Further information

http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

http://www.comodo.com/e-commerce/SHA-2-transition.php
http://www.quovadisglobal.com/en-GB/NewsAndEvents/20131205_QuoVadis_SHA256.aspx
http://googleonlinesecurity.blogspot.in/2014/09/gradually-sunsetting-sha-1.html

https://support.quovadisglobal.com/KB/a429/changes-to-security-indicators-the-chromium-browser.aspx

List of vendors that support SHA2:
https://support.quovadisglobal.com/KB/a417/what-supports-sha-256-certificates.aspx?KBSearchID=28102