ERR_INSECURE_RESPONSE conseils de remise en Javascript
Nous avons beaucoup d'appels ajax à partir de notre application Web et tout est une demande https (les mandats de notre équipe informatique), oui nous avons ouvert les en-têtes pour autoriser le cross-domaine. Mais le problème est que nous avons notre propre certificat personnalisé utilisé en interne pour toutes nos applications, donc en gros je reçois une erreur lorsque nous appelons ajax:
Impossible de charger la ressource: net :: ERR_INSECURE_RESPONSE
Si j'ouvre l'URL dans le navigateur et accepte les certificats, les appels ajax fonctionnent correctement. Donc ma question est, existe-t-il un moyen de gérer cela via Javascript? Ou l'ajout d'un certificat approuvé résoudrait-il ce problème? De plus, même après avoir ajouté un certificat de confiance, serais-je à nouveau confronté à un problème dans ajax?
Remarque: nous testons tout cela dans le navigateur chrome
Oui, l'ajout du certificat à la liste des certificats approuvés de l'utilisateur résoudrait votre problème. Tant que votre serveur est correctement configuré sur le serveur CORS (et il semble que ce soit le cas, en fonction de votre succès après avoir accepté le certificat), le certificat est votre seul problème.
HTTPS offre deux avantages de sécurité:
- Vous savez que le canal de communication est sécurisé entre vous et la personne à qui vous parlez (par exemple, quand Alice parle à Bob, elle sait que personne d'autre ne peut écouter)
- Vous savez à qui vous parlez est vraiment qui ils prétendent être (par exemple, quand Alice parle à
bob.comelle sait que c'est vraiment le serveur qu'elle appellebob.comet pas un imposteur)
Le premier avantage est automatique. Il est garanti par le protocole cryptographique et ne peut pas être supprimé (sauf par des attaques très complexes contre des failles de sécurité qui sont généralement corrigées très rapidement).
Le deuxième avantage n'est pas strictement un avantage technique: il s'agit de confiance. Les serveurs utilisent des certificats pour lier leur clé publique (qui accorde le premier composant de sécurité) à leur propre identité. Ces certificats de clé publique sont signés par des institutions approuvées par l'utilisateur appelées autorités de certification (CA).
Lorsque vous essayez de vous connecter à bob.com, le site vous donne une clé publique pour effectuer une communication sécurisée. Vous êtes sceptique et dites: "Bien sûr, cette clé publique me permettra de vous parler en toute sécurité, mais comment savoir que vous êtes vraimentbob.com? "Le serveur vous donne alors un certificat signé par l'AC qui dit:
Nous, l'autorité de certification VeriSign, qui jouissent d'une grande confiance pour mener à bien nos enquêtes, attestons par la présente que la clé publique suivante appartient vraiment à
bob.com:Clé publique:
ZGdlZGhydGhyaHJ0eWp5cmo...Signé de manière vérifiable,
VeriSign
Il existe de nombreuses autorités de certification importantes qui sont largement reconnues (par les systèmes d'exploitation et les navigateurs) pour émettre un certificat signé si et seulement si elles ont vérifié de manière fiable qu'une clé publique appartient vraiment à un nom de domaine. Étant donné que votre système d'exploitation fait déjà confiance à ces signatures, nous pouvons les utiliser sans aucune confirmation.
Lorsque vous utilisez un certificat auto-signé, aucune autorité de certification de confiance n'a vérifié que votre certificat appartient réellement à votre nom de domaine. N'importe qui peut produire un document qui dit:
Hé, mec, c'est à 100% la clé publique de
bob.com:Clé publique:
WGdoZmpodHlqa2p1aXl1eWk...Faites-nous confiance, les gars qui ont écrit cette note, d'accord? Nous sommes définitivement certains que c'est la clé. Les gars qui ont écrit cette note sont ceux qui dirigent
bob.com. On promet.Signé,
Les gars qui ont écrit cette note
Cela n'a pas de signature de confiance. L'utilisateur doit décider s'il souhaite accepter l'attestation du certificat que la clé publique appartient réellement à bob.com.
Prendre cette décision de manière significative est un processus difficile - vous devez inspecter le certificat et trouver un enregistrement approuvé préexistant de la clé publique quelque part (ou contacter un administrateur de site ou un représentant du service d'assistance). En effet, vous devez faire confiance au certificat par quelque part, car il ne provient pas de la signature de confiance d'une autorité de certification majeure.
Autoriser JavaScript à effectuer automatiquement cette détermination de confiance n'a aucun sens. Le fait est que tilisateur doit décider si le certificat est fiable ou non, puis apporter les modifications appropriées au magasin de certificats du système.
Ceci pourrait hypothétiquement être fait pour les requêtes Ajax, mais ce ne serait pas joli. Vous devez montrer à l'utilisateur un écran d'interface utilisateur de navigateur lui demandant si l'utilisateur souhaite faire confiance au certificat auto-signé pour le domaine auquel le script tente d'accéder. En plus d'être très perturbateur pour l'expérience de navigation, cela pourrait être dangereusement déroutant: si je suis sur example.com, et soudain (en raison des actions d'un script que je ne connaissais pas), on me demande de faire confiance à un certificat pour bob.com, Je pourrais l'accepter uniquement sur la base de ma confiance en example.com.
Ajoutez le certificat à la liste des certificats approuvés de vos systèmes ou faites-le signer par une autorité de certification déjà approuvée par vos systèmes.
L'ajout du certificat approuvé devrait être suffisant si tous les appels AJAX sont effectués dans le même domaine, s'ils ne sont pas du même domaine, en utilisant JSONP pour obtenir les données avec AJAX vous n'obtiendrez pas l'erreur.
Si vous souhaitez en savoir plus sur JSONP, voici un lien utile: http://www.sitepoint.com/jsonp-examples/