IE8 window.open Numéro de certificat SSL

Question

J'ai une application Web qui utilise un certificat auto-signé. Lorsque vous vous connectez à l'application, vous devez accepter le certificat. C'est une douleur, mais ... nous sommes d'accord avec ça pour le moment, et tout va bien. Lorsque vous cliquez sur le lien d'aide, il utilise le script java window.open pour ouvrir l'aide dans une nouvelle fenêtre. Tout cela fonctionne très bien. Sauf dans IE8.
Dans IE8, lorsque j'utilise window.open pour ouvrir le fichier d'aide, il demande de nouveau à l'utilisateur d'accepter le certificat SSL. C'est comme si c'était dans une nouvelle zone de sécurité ou quelque chose comme ça. Ce n'est pas un problème dans IE plus ancien, ou dans Firefox.

Est-ce que quelqu'un sait un moyen de contourner cela? Est-il possible d'ouvrir une nouvelle fenêtre mais de la garder dans la même session de sécurité?

Je ne veux pas une solution qui implique la configuration IE, je ne veux pas avoir à ajouter des étapes de configuration IE à notre guide d'installation! Et à ce stade, il n'est pas pratique de mettre un certificat approprié, autant que j'aimerais.

Mise à jour: L'URL de l'application est juste localhost: port. Le fichier d'aide est juste help.html. Nous avons le même problème avec la boîte À propos de. About.html.

Answer 1

Ce comportement est attendu pour IE8. Sauf si vous ajoutez le certificat de site à une liste d'exceptions permanentes, devrait être invité pour chaque nouvelle fenêtre que le site ouvre.

Vos choix sont:

• Acceptez votre certificat auto-signé de façon permanente
• Délivrer un véritable certificat
• intégrons les fenêtres supplémentaires dans celui déjà ouvert au lieu de fraie indésirable plus du navigateur
• Vivre avec devoir accepter le certificat une fois par fenêtre

Answer 2

L'opensource Forge projec Je pourrais peut-être aider. Il a été créé pour aider à résoudre ce problème: l'accès en toute sécurité des applications Web sans demander à l'utilisateur de traiter des avertissements de certificats auto-signés, etc.

Le projet Forge:

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

Un billet de blog parler de la question et comment Forge peut être utilisé pour le résoudre:

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

l'essentiel de c'est ceci: Forge propose deux façons pour vos utilisateurs pour éviter d'avoir pour traiter les avertissements de certificat. Cependant, les deux peuvent nécessiter une ingénierie de votre part qui peut ou non impliquer plus de travail que vous ne le pensez.

Méthode 1: Vous pouvez demander à vos utilisateurs d'accéder à l'application s'exécutant sur localhost via un site Web protégé par SSL (pas localement, mais via un domaine sur le Web). Pour permettre cela, Forge tunnels SSL via Flash, qui peut faire des demandes inter-domaines. Les détails de ce sont abstraits de tout ce que vous auriez à ajouter à votre demande. Vos utilisateurs iront tous sur le même site Web, ce qui est pratique et peut-être plus facile à retenir pour eux que "localhost: 12345", et télécharger du code JavaScript.Que JavaScript ferait alors des demandes de domaines croisés SSL à "localhost: 12345" pour afficher l'interface. Voici la partie re-engineering ... si votre application web n'utilise pas déjà ajax pour mettre à jour son contenu et afficher son interface, alors vous devrez le changer pour le faire. C'est parce que toute la magie inter-domaines et SSL se fait via JavaScript. L'autre partie dont vous avez besoin est la possibilité pour votre application de télécharger et de stocker les certificats auto-signés qu'elle génère sur le serveur auquel vos utilisateurs accèdent. De cette façon, il peut être inclus comme un certificat de confiance quand ils accèdent au site Web et téléchargent le JavaScript. Cette méthode garantit un trafic sécurisé vers l'application s'exécutant sur localhost sans les avertissements de sécurité gênants.

Si vous n'avez pas encore de site Web protégé par SSL ou si vous ne voulez pas en payer un, la méthode n ° 2 pourrait être plus attrayante.

Méthode 2: Cette méthode est légèrement moins sécurisée mais ne devrait pas représenter un énorme risque de sécurité puisque l'application s'exécute sur localhost. Cette méthode est également plus rapide à mettre en œuvre. Dans cette méthode, vous chargez le JavaScript Forge à partir du serveur localhost, avec le certificat à approuver. À partir de ce moment, le JavaScript de Forge effectue des appels https pour afficher l'interface/interagir avec l'application. Cela signifie que les mêmes changements d'interface ajax devront toujours être effectués comme dans # 1, cependant, aucun système ne doit être configuré pour stocker des certificats auto-signés (ou similaires). Encore une fois, l'inconvénient est que le certificat à faire confiance et le JavaScript de Forge sont chargés à l'origine sur une connexion non sécurisée. Cependant, cette connexion est à localhost donc c'est un peu moins d'inquiétude que si elle était chargée sur internet.

Il n'y a pas de travail ici, mais en fonction de la complexité de votre application ou de la façon dont vous l'avez déjà écrit, cela ne sera peut-être pas si difficile. Et, une fois cela fait, vos utilisateurs devraient avoir une expérience beaucoup plus lisse (sans aucune instruction supplémentaire pour accepter les certificats).