Transition to InCommon SSL Certificates with SHA-2

Printer-friendly version

Summary

If you maintain a server that uses an SSL certificate with a SHA-1 signature, you may need to obtain a new certificate to avoid web browsers receiving certificate warnings about weak encryption. Many SSL certificates in use today are signed by a Certificate Authority (CA) using the SHA-1 algorithm. This includes all certificates issued to UCSB by InCommon prior to October 1, 2014. Applications other than web servers may also be affected. Read on for more information, or skip to Recommendations

SHA-1 Background

SHA-1 is considered to be cryptographically weak, but there are no practical attacks known at this time. The CA industry has been planning to deprecate SHA-1 and migrate to the stronger SHA-2 algorithm before an attack becomes practical.

Browser Makers Force the Move to SHA-2

In November 2013, Microsoft announced that Windows would stop accepting SHA-1 certificates on 1/1/2017. More recently (August 2014) Google announced their timeline for deprecating SHA-1 certificates in Chrome. Google plans to successively phase in stricter warnings beginning in November 2014 and remove SHA-1 support completely at the same time as Microsoft; the announced schedule is as follows:

November 2014
SHA-1 SSL Certificates expiring any time in 2017 will show a warning in Chrome.
December 2014
SHA-1 SSL Certificates expiring after June 1, 2016 will show a warning in Chrome.
January 2015
SHA-1 SSL Certificates expiring any time in 2016 will show a warning in Chrome.
January 1, 2016
Microsoft will end trust for SHA-1 Code Signing Certificates without time stamps.
January 1, 2017
Microsoft and Mozilla will end trust for all SHA-1 SSL Certificates.

Based on information from Google, it appears that Chrome will use icons in the address bar to visually indicate degraded security. The visual indicators are sensitive to the certificate expiration date, with certificates expiring in 2017 targeted first, then those expiring in 2016. Certificates expiring in 2014 and 2015 will not be impacted.

Good information on Mozilla's plans for Firefox and Apple's plans for Safari is not yet available.

Recommendations

Based on current information, we recommend you take the following actions depending on your situation.

Your Situation Recommended Action Result
My certificate will expire in 2017 Request a new certificate before November 2014 You will get a certificate signed with SHA-2 that will expire in 1, 2, or 3 years depending on the lifespan you requested
My certificate will expire in 2016 Request a new certificate before January 2015 You will get a certificate signed with SHA-2 that will expire in 1, 2, or 3 years depending on the lifespan you requested
My certificate will expire in 2015 Request a new certificate as your expiration date approaches You will get a certificate signed with SHA-2 that will expire in 1, 2, or 3 years depending on the lifespan you requested
My certificate will expire in 2014 Request a new certificate as your expiration date approaches You will get a certificate signed with SHA-2 that will expire in 1, 2, or 3 years depending on the lifespan you requested

The process for requesting SSL certificates has not changed: SSL certificates may be requested by any member of the UCSB community by following the instructions for Acquiring SSL Certificates for Hosts in the "ucsb.edu" Domain.

Questions

See the FAQ page.

Getting Assistance

If you have questions concerning your InCommon SSL certificates and the migration to SHA-2, contact us at ssl@ucsb.edu.

Additional Reading

Acknowledgements

Much of the text of this page was copied from an excellent page written by the University of Washington:https://wiki.cac.washington.edu/display/infra/Transition+to+InCommon+SSL+Certificates+Signed+with+SHA-2

Questions may be directed to ssl@ucsb.edu.