Our site needs to provide SSL authentication with a number of older devices. These devices (mostly old Nokia Feature Phones) have a limited number of root certificates and are only able to authenticate using the SHA1 algorithm. SHA1 is being aggressively deprecated, which means that new certs issued are mostly issued using SHA256. While some CA’s will still issue SHA1 certs, they are not issued using older root CA’s as the base certificate.

Has anyone else run into a similar issue such that they need a certificate that authenticates entirely with SHA1 (we realize this is less secure, but necessary evil in order to accommodate older devices)?

Alternatively, we need a way to backport a SHA256 (I don’t know if this is even possible) cert such that an older device can handshake with that new cert. This new cert would still need to be signed by a root certificate in the same list.

  • Why don't you look for some feature phones that accept the new certificate? Issue a warning for your users alerting them that, due to some serious security concerns, your site needs to restrict access to phones that provide support for feature X. Give them a list of devices that you know that work with that. People wil understand. If they have seen any news (written or digital), they will know that his is a necessary measure. – DarkLighting Nov 11 '15 at 12:40
  • Have you thought about developing J2ME or BREW apps to add support for the new cert? – DarkLighting Nov 11 '15 at 12:41
  • Some CAs (I think all the ones I've looked at) have a new SHA256 root but also have a 'bridge' cert (aka 'compatibility' or 'transition') chaining the new root key and issuer back to an older SHA1 root. If you have your server include the bridge cert in the served chain, old client will chain to old root and work, but new client should 'bypass' the bridge and just verify against the new root. (Although OpenSSL below 1.0.2, and programs using it, don't.) – dave_thompson_085 Nov 11 '15 at 20:54

Basically, you can't both support older devices, and have the improved security of hashes signed using the more modern algorithm.

The push to eliminate SHA-1 has been extensive, and, by the usual standards of these things, remarkably quick. This isn't a bad thing - there are well documented problems with SHA-1 signed certificates, and while these are not currently viable for most attackers, the technology is improving all the time, and it is better to have completely deprecated SHA-1 signatures before the technology reaches the dangerous point.

There is very little that can be done to handle the lack of support for older root certificates. These are designed to expire after a while, and although the expiration has been brought forward, the plan was always to eventually stop using them.

Similarly, you can't backport a certificate signature. You can, obviously, sign the same certificate with two methods, although you can only use one of them for a given web server safely (unlike ciphers, SSL doesn't negotiate signature methods).

If you could find a provider willing to sign a certificate using the SHA-1 algorithm, with the older root certificate, you could direct feature phone users to a distinct version of the site using this, while other users get a version signed with the newer algorithm. In order to do this, you would need to have your landing page either running over HTTP, or signed with the older certificate, then redirect from there. If you sign it with the newer certificate, the older devices won't be able to access it, so will never reach the redirection.

This does present a security risk, but this might be considered acceptable, and the difficultly of finding a willing and able CA remains.

The other option would be to perform a similar operation, but self-sign the certificate for these devices. This doesn't solve the root certificate issue, but may allow for an encrypted connection, if users can manually accept the certificate (I don't know whether this is always possible on feature phones - been a while since I tried). This provides confidentiality without implicit trust provided by a CA, but you get to control the signature and other features of the certificate.

  • TLS does negotiate signature algorithms using extension: tools.ietf.org/html/rfc5246#section- if client doesn't send extension, sha1-only is assumed by server. Server can show different cert depending on client's value. Cloudflare do this. – Z.T. Nov 11 '15 at 12:44
  • True, but only for TLS 1.2 by spec. Given that there are still the odd smart phone that doesn't support TLS 1.2, I'm guessing that feature phones may lag even further behind. – Matthew Nov 11 '15 at 13:22
  • @Matthew: All modern browsers can do SHA-256 and also TLS 1.2. Thus if the client does not speak TLS 1.2 you could assume that it might not do SHA-256 either and sent the SHA-1 certificates. But a larger problem might be to find a CA from the set supported by the phone which will still issue SHA-1. – Steffen Ullrich Nov 11 '15 at 13:56
  • Especially given how small the CA sets tend to be for feature phones... – grawity Nov 15 '15 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.