SSL Certificates, SHA-2 & Why Should I Upgrade?

SHA-2 Compression Family Tree
When you order an SSL certificate for your website, your certificate is signed with a cryptographic hash algorithm that ensures the validity of the signed SSL certificate. In the distant past, SSL certificates were signed with an MD5 hash, but as computational power increased, MD5 became insecure. SHA-1 signing then became the new industry standard. However, SHA-1 has also become technologically insecure.

Sunsetting SHA-1

US NIST has recommended that SHA-1 no longer be used, and as of late 2014, the SSL Certification Authority industry has moved quickly to discontinue use of the SHA-1 hashing mechanism for SSL certificate signing in favor of SHA-2.

In order to facilitate this transition, major browser vendors, including Mozilla, Google, and Microsoft have announced relatively fast deprecation policies for SHA-1 signed certificates.

  • Microsoft will stop trusting any SHA-1 signed certificates after January 1, 2017. [1]
  • As of Chrome 41 (Mar 2015), Google Chrome will show SHA-1 certificates that expire after January 1, 2017, as insecure. SHA-1 certificates that expire between Jan 1 – Dec. 31, 2016, will be shown as “secure with minor errors”. [2]
  • Firefox will display a warning for SHA-1 certs after January 1, 2016, and stop trusting them after January 1, 2017. [3]

Using SHA-2

SHA-2 is actually a crypto family that includes six different hash functions, including SHA-224, SHA-256, SHA-384, SHA-512, etc. For SSL certificates, SHA-256 is what is used, so for the purposes of this article, SHA2 and SHA256 will be used interchangeably.

Issuing

All the major Certificate Authorities are now issuing SHA-2 certificates, but not necessarily by default. Some will give you SHA-2 by default. Some of them will allow you to choose SHA-1 or SHA-2 at the time of certificate ordering. Others will give you a SHA-1 or SHA-2 certificate depending on how you sign the CSR (with either a SHA-1 or SHA-2 signature) that you submit to them.

When you order an SSL certificate, in order to ensure that the CA receives a SHA-256-signed CSR from you, which will usually be a “signal” for them to issue you a SHA-256 cert, you need to use the “-sha256” flag during CSR generation, instead of the “-sha1” flag, like so:

openssl req -new -out www.domain.com.csr -key www.domain.com.key -sha256

Re-issuing

If you have a current SHA-1 certificate that expires after January 1, 2017, you’re probably going to want to reissue it with a SHA-2 signature, due to the web browsers eventually showing it as insecure. If you have an existing cert that expires in 2016, you may also want to reissue that, because of the security warnings that browsers will display.

Installing and Using

SHA-2 certificates are installed the same way as any SSL certificate, using Apache directives like this:

SSLCertificateFile /path/to/www.domain.com.crt
SSLCertificateKeyfile /path/to/www.domain.com.key
SSLCertificateChainFile /path/to/intermediate_cert.crt

One thing to be aware of is that SHA-2 certificates are usually signed by separate SHA-2 intermediate certs which are different from the SHA-1 intermediate certs that you may have seen or used previously. Therefore, it’s very important to make sure you obtain and install the correct intermediate certificate. SHA-2 intermediate certs ensure that there is a SHA-2 secured trust chain all the way to the root certificate (root certificates are mostly SHA-1 at this point, and that is not a problem since SSL roots are trusted by their identity, and not by their signature; essentially, signatures are not used for anything on root certificates).

Once installed, you can (and should) test that the certificate chain has been constructed correctly by testing it here:
https://www.sslshopper.com/ssl-checker.html

Testing

You can test your SSL certificate installation to see if it has SHA-2 signatures all the way to the root with this tool:

https://shaaaaaaaaaaaaa.com/

You can check any individual cert or CSR that you have to see if it was generated with a SHA-2 signature by pasting it into this tool:

https://certlogik.com/decoder/

Look for the field called “Signature Algorithm”, which will tell you if it’s SHA-1 or SHA-256.

Server requirements

On the server, you need a TLS/SSL stack that supports SHA-2 hashing, both for CSR generation, and for certificate reading/serving. Usually the server software (Apache, etc.) relies entirely on the encryption stack/OS to handle the hashing functions, so there’s nothing specific in software that needs to be updated, just the OS and/or SSL tools.

  • OpenSSL 0.9.8 or later (although 0.9.8o (or 0.9.8e-18 on CentOS 5) may be required for full compatibility with all applications)

The stock OpenSSL included in CentOS 5.0 or later includes support for SHA-2.

  • Windows Server 2003 with SP2 and KB2868626
  • Windows Server 2008 or later

Client requirements

On the client side, you also need a compatible OS and web browser that can properly understand SHA-2-hashed certificates.

Operating Systems

  • Windows XP SP3 or later
  • Mac OS X 10.5 Leopard or later

Desktop Browsers

Basically, if you’re using any modern browser, you should be fine.

Highlights:

  • Internet Explorer 6 or later (with SP3 when using XP)
  • Firefox 1.5 or later
  • Chrome 26 or later
  • Safari 3.0 or later

Mobile Browsers

  • iOS 3.0 or later
  • Android 2.3 or later
  • Windows Phone 7 or later

Tools/Libraries

  • libcurl / cURL 7.19.6 or later
  • Java 1.4.2 or later
  • Python 2.6.6 or later

By Todd Bangerter

Image via Wikipedia

Written By
More from admin

Superb.net FTP Usage Instructions: FTP (File Transfer Protocol)

Basic FTP Usage Instructions: Log-in using your FTP client with the following...
Read More