Summary
If you maintain a server that uses an SSL certificate with a SHA-1 signature, you will 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 CSUN by InCommon prior to October 1, 2014. Applications other than web servers may also be affected. CSUN will be transitioning it's central wild card certificates to SHA-2 in late 2015 or early 2016.
If you use the CSUN LDAP environment for authentication we recommend that you load the new intermediate certificates that are SHA-2 compatibile by June 27, 2015.
SHA-1 Background
SHA-1 is considered to be cryptographically weak, but there are no known attacks that can be done in real time to compromise secure web sites. The certificate 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 2016 or 2017 | Request a new certificate before November 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 |
| I use LDAP in my application | Load the intermediate certificates before June 27, 2015 | Your application will continue to work when the CSUN wild card is converted to SHA-2 |
The process for requesting SSL certificates has not changed: SSL certificates for the csun.edu domain may be requested by any faculty or staff member of the CSUN community. Please create a ticket and include the CSR in the request.
Questions
Q: How can I view details of my SSL certificate?
A: You can view details by browsing to your website and clicking the icon in your browser to view the SSL certificate. On the details screen for the certificate look for the "signature hash algorithm" and the "valid to" date. You can also use server tools like the openssl command.
Q: Requesting a new certificate instead of a renewal requires I submit a Certificate Signing Request (CSR). Is that extra work really necessary?
A: Yes. Unfortunately, that is the only way to get a SHA-2 certificate. If you still have the CSR you used to create your SHA-1 certificate, it's possible to use it again to get a SHA-2 certificate. Otherwise, you'll need to create a new CSR.
Q: How can I request a replacement SSL certificate for my server?
A: Submit a certificate signing request (CSR) containing the exact same information as the original in your support case.
Q: How is LDAP affected?
A: An application connects to the campus LDAP via a secure connection. The client connection (your application) will need to have the SHA-2 compatible intermediate certificates in your key store in order to function.
Q: My web server has the InCommon intermediate certificate (InCommon Server CA) installed. It appears to be signed with SHA-1. Do I need to get a new intermediate certificate too?
A: Yes. SHA-2 SSL certificates depend on a new set of CAs, each with their own SHA-2 certificates. In the past there was only one intermediate certificate, but for SHA-2 there are two. You will need to have both of these intermediate certificates installed on your web server in order for browsers to follow the chain to a trusted root certificate.
One of InCommon's two new intermediate certificates was signed with SHA-512. (SHA-2 is a family of algorithms that includes SHA-256, SHA-384, and SHA-512.) The SHA-512 intermediate has been found to have some interoperability issues so, as of today, that intermediate CA is using a new certificate signed with SHA-384. The original SHA-512 certificate is still valid for any InCommon SSL certificates issued from 10/1/2014 through 10/5/2014 that include the SHA-512 certificate in their chain of trust.
Q: What will happen if I don’t migrate to an SSL certificate signed with SHA-2?
A: That depends on the browser, the expiration date for the certificate, and the current date. Initially the user may see warnings or changes in the security icons used in the address bar. By 1/1/2017 all major browsers will reject certificates signed with SHA-1.
Q: What are the InCommon intermediate certificates and where can I get them?
A: Certificates issued from 10/1/2014 through 10/5/2014 use a different certificate chain than those issued 10/6/2014 and later:
- 10/1/2014 through 10/5/2014: AddTrustExternal CA Root > UserTrust RSA Certification Authority > InCommon RSA Server CA (SHA-512) > your SSL certificate
- On or after 10/6/2014: AddTrustExternal CA Root > UserTrust RSA Certification Authority > InCommon RSA Server CA (SHA-384) > your SSL certificate
If you download your certificate in the PKCS7 format, the correct intermediate certificates will automatically be included. If you download the PEM format you will only receive your SSL cert but instructions and a link to obtain the intermediate certificates is provided. See InCommon SSL Intermediate Certificates.
Q: Does this only affect people who are using SSL certificates for HTTPS connections to a webserver, or does it also affect other protocols or servers?
A: If your server encrypts connections with SSL, you should upgrade its certificates to SHA-2. The most common and visible impact will be for HTTPS connections, but IMAPS or LDAPS or other SSL-protected connections also need to be upgraded before end-users' operating systems end support for SHA-1 certificates.
Q: Why is my server's SHA-2 certificate still untrusted by Firefox?
A: If you are running an Windows IIS server, then there are apparently some undocumented steps you must take to get the certs working with Firefox. Chrome and I.E. don't seem to have the problem.
Here they are:
- Open a blank MMC and add "Certificates" in the Local Computer context.
- Open the "Trusted Root Certification Authorities / Certificates" folder.
- Find the certificate "USER Trust RSA Certification Authority" (expires 1/18/2038<x-apple-data-detectors://0>) and delete it.
- Open the "Intermediate Certification Authorities / Certificates" folder.
- Verify the presence of "InCommon RSA Server CA" (expires 10/5/2024<x-apple-data-detectors://1>) and "USER Trust RSA Certification Authority" (expires 5/30/2020<x-apple-data-detectors://2>).
- Run gpedit.msc
- Drill down to Computer Config | Admin Templates | System |Internet Communication Management | Internet Communication Settings
- Locate "Turn off Automatic Root Certificates Update" and change the setting to "Enabled".
- In IIS Manager, delete the HTTPS binding from your server instance and re-create it. Bind your SHA256 certificate.
- Restart the World Wide Web Publishing Service.
Getting Assistance
If you have questions concerning your InCommon SSL certificates and the migration to SHA-2, contact us at iso@csun.edu.
Additional Reading
- SHA1 Deprecation Policy (Microsoft)
- Microsoft Retiring SHA-1 in 2016 (Bruce Schneier)
- Intent to Deprecate: SHA-1 certificates (Google)
- Why Google is Hurrying the Web to Kill SHA-1
- Gradually Sunsetting SHA-1 (Google)
- SHA-256 Compatibility (GlobalSign)
