In a recent project using Azure, SSL worked perfectly on all devices – but those running Android 2.X. It turned out that legacy Android has limited support for modern SSL/TLS features such as SNI and subject alternative name.

Getting TLS configuration right nowadays can be quite tricky. Google Chrome is aggressively pushing for deprecation of old insecure standards by showing warnings or even errors on sites using deprecated https settings. Using a certificate issued merely two years ago, with the standards where common then now shows an error because the SHA-1 algorithm is not considered to be safe for the two remaining years of the lifetime of the certificate. The Google Chrome team is definitely pushing hard for moving web cryptography to safer grounds.

On the other end of the scale (no, I won’t be complaining about Windows XP, it’s not that much of a problem any more) is another Google product: Android. Even with the blazingly fast technology development, people are (IMHO rightfully) expecting a multi €100-device to last for more than a few years. That means that a lot of devices out there are still running Android 2.X. In this particular project, the target audience are not that tech-savvy. A lot of the users even have had to invest in their first smart phone, making their call-and-sms-only phones to history. With that audience, we had to support those old devices. On the other hand SSL warnings or errors in Chrome was unacceptable, so we had to find something that worked for all those platforms – and we did. Oh and by the way, the budget was really, really tight, so we had to find something that wasn’t too expensive.

The Constraints

To work both we Chrome and legacy Android, we had to find a solution that fit within the constraints set by the platform.

• IP-based SSL, there is no working SNI (Server Name Indication) support in legacy Android.
• Certificate issued to main name of the site, Android doesn’t look in subject alternative name field.
• Certificate signature should use SHA256.

The Setup

The project is running on an Azure standard site, using the build in TLS support. The certificate is a free one from StartSSL. When we first tried, we got stuck with certificate warnings on the legacy phones.

These are the steps we took to make it work.

1. Set up the Azure site with IP based TLS.
2. Made sure the DNS points to the IP address assigned for TLS. At first it used the CNAME and that didn’t work (although I think Azure might have fixed that now, the Azure DNS records looks a bit different than when we did this setup.
3. We wanted a site name without www. When issuing a certificate at StartSSL a subdomain must be given. The certificate is then issued to that subdomain.example.com with a subject alternative name of example.com. To work around that and get a certificate for the bare domain a single . can be entered in the subdomain field.