Controlling the User Experience when SSL Root Certificates are not Recognised by Browsers

Yup, we all know SSL is the way to go when protecting your site’s traffic from the bad guys, and it is not that difficult to set up. But what happens when the browsers don’t have pre-installed CA root certificates for the issuer of your SSL certificates? They tend to present very scary messages. Some versions of Internet Explorer heartily recommend users to get away from your site as quickly as possible, lest they be eaten by evil monsters (well, not exactly, but it has a similar effect).

Scare tactics may work well for browser manufacturers, so that certificate issuers are willing to make their certificates recognised and pre-installed in these browsers (or OS) releases. This process might involve some payment to the browser’s manufacturer… (warning: this is my personal unproven claim… call me suspicious if you wish).

In any case, once the user clicks on a link to your secure SSL-protected HTTPS site, funnily enough, the browser’s alarm messages may make it appear as a more insecure choice than using HTTP. What the …?

It looks like you don’t have control over the user’s experience… or do you?

We at Isigma have devised a mechanism that does give you some control over what your users see, and at least skip the browser’s message and replace it by your own page. It involves some Javascript Ajax. We have written it with jQuery but you can use any equivalent Ajax library of choice.

How can I Replace the Browser’s Unrecognised SSL Certificate Message?

Our solution consists of having a plain HTTP welcome page that checks behind the scenes whether the browser can open the HTTPS page, and if so does an automated redirect to the secure page. If the redirect doesn’t happen, it shows a message informing the user that in order to access your site she should install the root certificates, and instructing her how to do so.

For that purpose we created a jQuery-based javascript function ssl_check_and_redirect that honors its name. You give it an https URL, and if the browser can open it with Ajax, it redirects you automatically.

The datatype of “script” is a useful trick to avoid browsers’ same-origin policy restrictions when performing Ajax calls.

Unfortunately, if you try to use an error callback for the case where the SSL certificate is not recognised (I know that’s what you’re thinking, because it’s what I thought), you’ll find out that it is never called. To detect that case, you may want to use a workaround based on some sort of timeout instead.