How-to Instructions

About SHA-2 Certificates

To accommodate browser vendors' plans to phase out support for SHA-1 signed certificates, InCommon has now made available certificates signed using the SHA-2 hash family.

This information was originally presented at a net-people meeting, 2014-10-09.

How can I get a SHA-2 signed cert? 

When requesting an SSL certificate, choose a Certificate Type from the dropdown that has SHA-2 in the name.

An image illustrating the Certificate Type options in the SSL Certificate Manager application.

When the certificate is issued, be sure to download and install the intermediate and root certificates as well, as the SHA-2 certs are issued from a new intermediate CA. IIS admins will normally download the PKCS#7 file, which already includes the necessary certs in one file.

Beware: some versions of IIS (IIS7 on 2008 and 2008R2 at least) may not correctly send all of the intermediate certificates unless you remove and recreate the HTTPS binding from the site. The symptom of this would be recent IE and Chrome working with your site, but Firefox giving certificate warnings.

Why should I get a SHA-2 signed cert? 

Security researchers have found weaknesses in the collision resistance of SHA-1, which reduces the predicted costs of a brute-force collision search significantly. In response, browser vendors have accelerated their plans to phase out acceptance of SHA-1 certificates, with Chrome and Firefox leading the charge and Internet Explorer not far behind. Starting in January 2015, some browsers will begin to show security warnings for sites secured with SHA-1 signed certificates that expire after January 2017, with timeframes tightening up in the months that follow.

One consequence of this is that the InCommon Certificate Service now limits the lifetime of SHA-1 signed certificates to 1 year.

Why shouldn't I get a SHA-2 signed cert? 

While most current browsers, web servers, and operating systems support SHA-2 certs, some in use at the University of Minnesota do not. Server administrators will need to consider their client base when deciding on the time to switch. Here are some general guidelines to assist in making these decisions.

If you run a publicly-facing general purpose web server with a typical range of browsers, the vast majority of your clients are likely to support SHA-2. You could request a 1 year SHA-1 cert now, and plan to deploy a SHA-2 cert when the SHA-1 cert is due to expire. This would give your users the maximum time to have any necessary software updates installed, while avoiding error messages from the newer browsers.

If you run a more focused site that serves a limited population, you could check system logs to identify the browsers and platforms that are being used on your site, and decide whether and how you might want to make the switch. The process above for a publicly-facing site should work OK for this situation as well.

If you have or can influence administrative control over your users' browsers, you may be able to move to SHA-2 immediately, depending on what browsers the users must use. If they are all ready for SHA-2, go ahead and get a SHA-2 cert now. If they are not, you don't need to worry about SHA-1 warnings. But you won't be able to acquire a new SHA-1 cert after December 2015, so you will need to make alternative arrangements, such as using a self-signed certificate and distributing it to your browsers directly.

If you run non-web SSL services (e.g. IMAPS, LDAPS, SMTPS), you'll have to carefully consider your client base. End users running IMAP clients based on current SSL libraries may experience the same kinds of warning messages as browsers, while older LDAP clients might not be capable of handling SHA-2 certs without modification. If you have old server software that will need to interoperate with newer client software, you should plan to update your software sometime over the next year. If you have to support older clients, you might need to arrange for clients to trust self-signed certs directly.

How old is too old to support SHA-2? 

GlobalSign has a set of tables summarizing SHA-2 (specifically, SHA-256) compatibility with major operating systems, browsers, and other products.

OpenSSL 0.9.8o and above support SHA-2 out of the box; previous versions can support it if the SSL initialization code includes an extra call to OpenSSL_add_all_algorithms().

Do I need to generate a SHA-2 signed CSR to get a SHA-2 signed cert? 

No. The signature in a certificate signing request (CSR) is only used as part of a "proof of possession" of the corresponding private key. It is only used once, at certificate request time, and has no impact on the contents of the resulting certificate. The CA will sign your certificate according to its policies, using whatever hash is specified. So for certificate types containing "SHA-2", the certificates will always be signed with a SHA-2 hash; for types without "SHA-2", SHA-1 will be used instead.