Obtaining SHA-2 Certificates
Google has announced that they will deprecate SHA-1 encrypted SSL certificates in Chrome beginning November 2014. This effects all certificates issued via UF’s InCommon certificate program.
As you may have heard, Internet Explorer, Chrome and Firefox Web browsers will discontinue the ability to use HTTPS/SSL certificates created with SHA-1 encryption and instead will require the use of SHA-2 secure hash. For more information on how Google will begin deprecating SHA-1 certificates in Chrome visit this article.
Windows and Internet Explorer, newer versions of Mac OS X, Firefox, Chrome, Opera, Safari, Java and Adobe Acrobat/Reader all support SHA-2.
What does this mean for UF?
Google’s decision to aggressively deprecate SHA-1 affects every UF service provider who is using certificates issued by InCommon.
UFIT has begun working internally on our plan to rapidly address the large number of certificates that we are responsible for – all hosted websites, managed enterprise applications, and other centrally-provided campus services that use SSL (mail systems, etc).
While the focus of this announcement is on the InCommon SSL certificate service, it should be noted that this issue affects the industry broadly, so IT practitioners who have acquired certificates from other sources should audit those certificates as well.
How can you prepare for this change?
Web site/Service owners using HTTPS/SSL Certificates should take inventory of their certificates and plan on migrating affected SHA-1 SSL certificates before November 2014.
If your website is hosted within UFIT’s Apache or IIS web hosting environment UFIT will handle replacing your certificate prior to Google’s deprecation date, so you don’t have to do anything.
Can my server accept a SHA-2 Certificate?
Software and Hardware that support SHA-2: https://www.digicert.com/sha-2-compatibility.htm
Who will be impacted by this change?
Your websites’ users may experience negative visual security indicators if the SHA-1 certificates are valid beyond December 31, 2015. Google Chrome users will begin seeing these warning beginning November 2014. Additionally, if a user is on Windows, they will not be able to access sites with SHA-1 certificates after January 1, 2017.
Is SHA-1 still Safe? Why do I need to migrate?
Certification Authority/Browser (CA/B) Forum and industry leaders are proactively looking for ways to help secure web environments and infrastructure. SHA-1 has been a widely accepted industry standard, however, SHA-2 contains a number of improvements to strengthen security. In addition, National Institute of Standards (NIST) has recommended its use instead of SHA-1.
Does SHA-1 migration apply to code signing certificates?
Yes. Although code signing certificates are not included in Google’s SHA-1 deprecation plan, they are affected by Microsoft’s plan.
1. Check Environment for SHA-2 Certificate Support
The first step is to ensure that your environment, including both software and hardware, will support SHA-2 certificates. Refer to the SHA-2 compatibility page for a list of supported hardware and software. If parts of your environment will not support SHA-2, you must replace or upgrade those pieces before you can implement new certificates.
2. Find All Certificates
Inventory all of the certificates in your environment.
If you are using certificates obtained via UF’s contract with InCommon, you can use the InCommon Certificate Manager to generate a custom report (CSV) of all of your certificates expiring after January 1, 2016. To do this, click the ‘Reports’ tab, and use the pull-down menus to select Reports -> SSL Certificates, Current Status -> Issued and Date Selection -> Expiration Date. Then set the To: date field to January 1, 2016.
3. Generate New CSRs for Each Certificate
Generate a SHA256-signed Certificate Signing Requests (CSR) for any certificates still using SHA-1 on the server where they are installed. You may need to modify the procedure you use to generate a CSR; for example, if you are using openssl, you will need to add the “-sha256” option as described here: https://www.tbs-certificates.co.uk/FAQ/en/192.html
4. Replace SHA-1 Certificates with SHA-2 Certificates
The procedure to obtain a SHA-2 certificate from your Certificate Provider should be much the same as it was before; if you have questions, please contact your Certificate Provider directly.
If you are obtaining certificates from Comodo via InCommon’s contract with UF (ie: using the InCommon Certificate Manager), you simply need to select one of the SHA-2 certificate options in the “Type” pull-down menu. At this time, you must re-enroll to obtain a SHA-2 signed certificate; you cannot use the “replace” function.
5. Download new certificates
Note that for new certificates using SHA-2 the Intermediate certificate chain has also been updated.
6. Install New SHA-2 Certificates
Once you receive your new certificates, install them on your systems. Remember to install the new Intermediate certificate chain to match the new certificate.
7. Test Certificate Installation
The last step is to test your website(s) and make sure that the certificates are installed, are working properly, and to ensure that you have not introduced any other potential vulnerabilities based on how you configured the certificates.
How will this change be communicated at UF?
In addition to this communication UFIT is planning to exercise the following other communication channels:
• IT Discussion List
• IT Directors Meeting Channels
Where can I get more information about this change?
Additional Details of the SHA-1 deprecation timeline:
What does InCommon say about this transition?
Here’s an email from InCommon (Comodo Certificate Authority) regarding the availability of SHA-2 certificates:
Sent: Monday, September 22, 2014 12:29 PM
Subject: [cert-users] SHA-2 signed SSL certificates within InCommon CM are now officially live!
Without further ado I present to you… SHA-2 signed SSL certificates!
SHA-2 signed SSL certificates can be easily obtained within InCommon by selecting the appropriate certificate type when requesting a new certificate. [ e.g. InCommon SSL (SHA-2) ]. Unfortunately, because these new certificate types are unique products within InCommon CM, you MUST re-enroll for a new certificate if you wish to have a SHA-2 signed certificate issued to you and because of this; using the “Replace” function is unfortunately out of the question at this moment in time.
Furthermore, SHA-1 signed SSL certificates are still available to InCommon CM but they are limited to one (1) year in length due, in part, to Google’s accelerated sunset of SHA-1 signed certificates.[ http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html ]. We apologize for any inconveniences this may cause.
*Please also be advised that with the new SHA-2 profiles there are new OCSP/CRL URIs available: ocsp.incommon-rsa.org & crl.incommon-rsa.org.
If your systems rely on the whitelisting of DNS Names, then please take note of this change!
* We recommend that you gradually replace all SHA-1 issued certificates with a new SHA-2 signed certificate prior to the end of December 2014.
** As of Sept/October 2014, we do not see any need to rush to re-issue certificates immediately, much like we saw earlier in the year a la Heartbleed (The OpenSSL bug).
* It is possible through InCommon CM to generate a custom report (CSV) of all of your certificates expiring after certain time.
** In order to accomplish this click the ‘Reports’ tab. Select “SSL Certificates” and set the “Date Selection” drop-down to “Expiration Date”.
** We recommend selecting an expiration date range containing dates beyond 1 January 2016.
If Comodo can be of any further assistance during this transition from
SHA-1 to SHA-2, please do not hesitate to reach out to our Support department via the details located at the InCommon Certificate Support site. [ https://www.incommon.org/certificates/support ]