SHA-1 Certificates Stop Working in January: Check Yours Now

The long goodbye to SHA-1 certificates is nearly over. Chrome 56, currently scheduled for release at the end of January, is planned to stop trusting publicly issued certificates signed with SHA-1 entirely. Firefox 51, due around the same time, is planned to do the same. Microsoft has announced that Edge and Internet Explorer will follow in mid-February.

"Stop trusting" means a full-page certificate error, not a small warning in the address bar. A visitor on an up-to-date browser won't reach your site without clicking through an interstitial that most people, reasonably, won't click through.

Most sites are fine. Certificate authorities have been prohibited from issuing SHA-1 certificates from the publicly trusted roots since January 1st of this year, so anything you've bought or renewed in 2016 is almost certainly SHA-256. The risk is in the corners: certificates bought in 2015 with long validity periods, intermediate certificates that nobody looked at, and servers that were set up once and never touched. This post covers how to find them.

Why SHA-1 is being retired

SHA-1 is a hash function. When a CA signs a certificate, it signs a hash of the certificate's contents, so the security of the signature depends on nobody being able to produce a different certificate with the same hash. That property is called collision resistance, and SHA-1's has been eroding for over a decade.

No one has publicly demonstrated a full SHA-1 collision yet. But researchers have shown attacks on SHA-1 that are far cheaper than brute force, and cost estimates for a practical collision have been falling each year as computing gets cheaper. The concern is not theoretical: in 2008, researchers used an MD5 collision to create a rogue CA certificate that browsers would have trusted. MD5 was known to be weak for years before that happened. The industry would rather not repeat the experience with SHA-1, so the deprecation is happening before a working attack rather than after.

Browsers have been warning in stages. Chrome began degrading the padlock for some SHA-1 certificates back in 2014, depending on their expiry date. January's change is the last step.

What exactly is affected

The rule applies to certificates in the chain that browsers actually verify:

• Your leaf certificate (the one for your domain). If it's signed with SHA-1 and chains to a public root, it breaks.
• Intermediate certificates between your leaf and the root. An SHA-256 leaf signed by an SHA-1 intermediate is still a problem, because the intermediate's signature is checked too.
• Root certificates are not affected. Roots are trusted because they're in the browser's store, not because of their self-signature, so an old root with an SHA-1 self-signature is fine.

There's also an exception for privately managed roots. Certificates from an internal company CA that's been added to machines by an administrator aren't covered by the January change in the same way, though the browser vendors have said that support will go too. If your intranet runs on an internal CA that still signs with SHA-1, plan to fix it anyway.

How to check your certificates

For a single site, look at the signature algorithm on each certificate the server sends. With OpenSSL:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | awk '/BEGIN CERT/,/END CERT/' \
  | csplit -s -z -f cert- - '/BEGIN CERT/' '{*}'

for c in cert-*; do
  openssl x509 -in "$c" -noout -subject -issuer -text | grep -E "Subject:|Issuer:|Signature Algorithm" | head -3
  echo
done

You're looking for sha256WithRSAEncryption (or an ecdsa-with-SHA256 variant) on every certificate except the root. Any sha1WithRSAEncryption on the leaf or an intermediate needs fixing.

Things to check beyond your main website:

1. Every hostname, not just www. API endpoints, mail servers' web interfaces, admin panels, staging servers that customers can see, and the marketing microsite someone set up in 2014.
2. Load balancers and CDNs. If a provider terminates TLS for you, the certificate they serve is the one that matters. Check what the public actually receives, not what's on your origin.
3. Stale intermediate bundles. A common problem: the certificate was renewed as SHA-256, but the server is still configured with an old intermediate file from the previous certificate. Browsers sometimes paper over this by building a different path, sometimes they don't, and results vary between browsers. Serve the chain your CA currently provides.
4. Long-lived certificates bought in 2015. Some CAs sold SHA-1 certificates with expiry dates well into 2017 and beyond. They'll still be inside their validity period in January, and they'll still fail.

Replacing a certificate

If you find an SHA-1 leaf, the fix is a new certificate. Most CAs will reissue for free within your existing term; ask for a reissue with a new CSR:

openssl req -new -newkey rsa:2048 -nodes -sha256 \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com"

Install the new certificate together with the intermediate bundle the CA sends with it, reload the server, and run the check again from outside. If the site already uses Let's Encrypt, you're fine: it has only ever issued SHA-256 certificates.

The compatibility question

There's one legitimate reason some sites held on to SHA-1: very old clients. Windows XP before Service Pack 3 and some old Android and embedded devices can't validate SHA-256 certificates. For almost every website this audience is tiny, and those clients have much bigger security problems. A few payment and point-of-sale environments with old hardware have had to make more careful plans, and the CA/Browser Forum has granted a small number of narrow exceptions for them.

If you have a real population of such clients, the answer usually isn't to keep SHA-1 on your public site. It's to serve them from a separate hostname with a separate configuration and let the mainstream site move on.

Put a date in the calendar

Browser release dates slip occasionally, so treat "late January" as approximate and aim to be done by Christmas. After that, the thing to watch is drift: the next person who renews a certificate or rebuilds a server with an old config file can reintroduce the problem.

As more of the web moves to HTTPS (we made the case for it earlier this year), browser policy decides more and more of what counts as a working site. The SHA-1 sunset won't be the last change of this kind. Checking your certificates from outside on a regular schedule, and alerting when something about them changes, is cheap protection against the next round. That kind of external certificate checking is part of what we do at CompleteStatus.