IE8 SSL certificate window.open error

Question

I have a web application that uses a self-signed certificate. Upon entering the application you need to accept the certificate. It’s a pain, but ... everything is fine with you, and everything is fine. When you click the help link, it uses java script window.open to open the help in a new window. All of this works great. Except for IE8.
In IE8, when I use window.open to open the help file, it again asks the user to accept the SSL certificate. It looks like a new security zone or something like that. This is not a problem in older IE or in Firefox.

Does anyone know about this? Is there a way to open a new window, but keep it in the same security session?

I don’t want the solution to include IE configuration, I don’t want to add IE configuration steps to our installation guide! And at this stage, it is impractical to enter the proper certificate as I would like.

Update: The application url is only localhost: port. The help file is only help.html. We have the same problem with the "About" field. About.html.

Answer 1

This is the expected behavior for IE8. If you do not add the site certificate to the list of permanent exceptions, you should receive a request for each new window that the site opens.

Your options:

• Accept your self-signed certificate on an ongoing basis
• Issue a real certificate
• Integrate additional windows into already open ones, and do not create more inactive browser.
• Live with the need to accept a certificate once per window

Answer 2

An open source Forge project can help. It was created to solve this problem: secure access to web applications, without requiring the user to deal with self-signed warnings, etc.

Forge Project:

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

A blog post about a problem and how Forge can be used to solve it:

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

The bottom line is this: Forge provides two ways for your users to avoid having to deal with certificate alerts. However, both of them may require some engineering on your side, which may or may not include more work than you consider its worth.

Method 1:. Your users can access the application running on the local hosting through a secure SSL site (not locally, but through a domain on the Internet). For this to happen, Forge tunnels SSL through Flash, which can handle cross-domain requests. The details of this abstract away from everything you would need to add to your application. Your users will go to the same website, which is convenient and perhaps easier to remember than "localhost: 12345" and load some JavaScript. Then, JavaScript would execute cross-domain SSL requests on "localhost: 12345" to display the interface. This is part of reengineering ... if your web application does not already use ajax to update its content and display its interface, then you will need to change it. This is because all cross-domain and SSL magic happens via JavaScript. The other part that you need is the ability for your application to download and store the self-signed certificates that it creates on the server that your users are accessing. Thus, it can be included as a trusted certificate when accessing the website and loading JavaScript. This method provides secure traffic for an application running on the local host without annoying security warnings.

If you don’t have a secure SSL site yet or don’t want to pay for it, then method # 2 may be more attractive.

Method 2: This method is slightly less secure, but should not be a huge security risk, since the application runs on localhost. This method is also faster. In this method, you download Forge JavaScript from the localhost server along with a certificate that you should trust. From now on, JavaScript Forge creates https calls to display the interface / interaction with the application. This means that all the same changes to the ajax interface should still be made, as in # 1, however, you do not need to install a system to store self-signed certificates (or the like). Again, the disadvantage is that the certificate to be trusted and JavaScript Forge are initially loaded over an insecure connection. However, this connection is connected to the local host, so it is somewhat less disturbing than if it were downloaded over the Internet.

Thus, there is no zero work here, but depending on the complexity of your application or how you wrote it already, it may not be that difficult. And, once this is done, your users should have a much smoother experience (without any additional instructions for accepting certificates).