IE8 window.open SSL Certificate issue

Question

I have a web based application that uses a self signed certificate. When you log into the application, you have to accept the certificate. This is a pain, but..we are OK with that for the time being, and everything is fine. When you click on the help link, it uses java script window.open to open the help in a new window. This all works fine. Except in IE8.
In IE8, when I use window.open to open the help file, it again asks the user to accept the SSL certificate. It is like it is in a new security zone or something. This is not an issue in older IE, or in Firefox.

Does anyone know a way around this? Is there a way of opening a new window but keeping it in the same security session?

I don't want a solution that involves IE configuration, I don't want to have to add IE configuration steps to our install guide! And at this stage it is not practical to put in a proper certificate, as much as I would love to.

Update: The url of the application is just localhost:port. The help file is just help.hmtl. We have the same problem with the About box..About.html.

Answer 1

This is expected behavior for IE8. Unless you add the site certificate to a list of permanent exceptions, you should get prompted for each new window the site opens.

Your choices are:

• Accept your self-signed certificate permanently
• Issue a real certificate
• Integrate the extra windows into the already-open one instead of spawning more browser junk
• Live with having to accept the certificate once per window

Answer 2

The opensource Forge project might be able to help. It was created to help solve this problem: securely accessing Web-based applications without requiring the user to deal with self-signed certificate warnings, etc.

The Forge project:

http://github.com/digitalbazaar/forge/blob/master/README

A blog post talking about the issue and how Forge can be used to solve it:

http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/2/

The gist of it is this: Forge provides two ways for your users to avoid having to deal with certificate warnings. However, both of them might require some engineering on your end that may or may not involve more work than you think its worth.

Method 1: Your can have your users access the application running on localhost via an SSL-protected website (not locally, but via a domain on the web). To enable this to happen, Forge tunnels SSL through Flash, which can do cross-domain requests. The details of this are abstracted away from anything you would have to add to your application. Your users would all go to the same website, which is convenient and perhaps easier for them to remember than "localhost:12345", and download some JavaScript. That JavaScript would then do SSL cross-domain requests to "localhost:12345" to display the interface. Here's the re-engineering part ... if your web-based application doesn't already use ajax to update its content and display its interface, then you would need to change it to do so. This is because all of the cross-domain and SSL magic happens via JavaScript. The other part you would need is the ability for your application to upload and store the self-signed certificates it generates to the server your users access. This way it can be included as a trusted certificate when they access the website and download the JavaScript. This method ensures secure traffic to the application running on localhost without the annoying security warnings.

If you don't already have an SSL-protected website, or don't want to pay for one, then method #2 might be more attractive.

Method 2: This method is slightly less secure but shouldn't be a huge security risk since the application is running on localhost. This method is also quicker to implement. In this method, you load the Forge JavaScript from the localhost server, along with the certificate that is to be trusted. From that point forward, the Forge JavaScript makes https calls to display the interface/interact with the application. This means that the same ajax interface changes will still need to be made as in #1, however, no system must be set up to store self-signed certificates (or similar). Again, the drawback is that the certificate to be trusted and the Forge JavaScript are originally loaded over an insecure connection. However, that connection is to localhost so it is somewhat less of a concern than if it were loaded over the internet.

So there isn't zero work involved here, but depending on the complexity of your application or how you've already written it, it might not be that difficult. And, once its done, your users should have a much smoother experience (without any extra instructions for accepting certs).