ERR_INSECURE_RESPONSE在Javascript中处理提示 [英] ERR_INSECURE_RESPONSE handing tips in Javascript

问题描述

我们的Web应用程序有很多ajax调用，而且所有内容都是https请求（我们的IT团队要求），是的，我们已经打开了标题以允许跨域。但问题是我们在内部为所有应用程序使用了自己的自定义证书，所以基本上我在调用ajax时出错：

We have a lot of ajax calls from our web application and the thing is all are https request (our IT team mandates), yes we have opened up the headers to allow cross domain. But the problem is we have our own custom certificate used internally for all of our apps so basically I get error when we call ajax:

失败加载资源：net :: ERR_INSECURE_RESPONSE

Failed to load resource: net::ERR_INSECURE_RESPONSE

如果我在浏览器中打开URL并接受证书，则ajax调用正常。所以我的问题是，有没有办法通过Javascript处理这个？或者添加可信证书会解决此问题？即使在我们添加可信证书后，我还会在ajax中遇到任何问题吗？

If I open the URL in browser and accept the certificates the ajax calls works fine. So my question is, is there a way to handle this via Javascript? Or would adding trusted certificate would resolve this issue? Also even after we add trusted certificate would again I face any issue in ajax?

注意：我们正在测试Chrome浏览器中的所有这些

Note: We are testing all these in chrome browser

推荐答案

是的，将证书添加到用户的可信证书列表中可以解决您的问题。只要您的服务器正确设置为服务器CORS（看起来就像是接受证书后的成功），证书是您唯一的问题。

Yes, adding the certificate to the user's list of trusted certificates would solve your problem. As long as your server is set up to server CORS correctly (and it seems like it is, based on your success after accepting the certificate), the certificate is your only problem.

HTTPS提供两个安全优势：

HTTPS provides two security benefits:

1. 您知道您和您正在与之交谈的人之间的通信渠道是安全的（例如，当Alice与Bob交谈时，她知道其他任何人都不能听。）


2. 你知道与你交谈的人他们真的是谁（例如当Alice与 bob.com 交谈时，她知道这是她认识的服务器 bob.com 而不是冒名顶替者）

1. You know that the communication channel is secure between you and whoever you're talking to (e.g., when Alice talks to Bob, she know no one else can listen in)
2. You know who you're talking to is really who they claim to be (e.g., when Alice talks to bob.com she's knows it's really the server she knows as bob.com and not an impostor)

第一个好处是自动的。它由加密协议保证，不能被剥离（除非通常非常快速地修复安全漏洞的非常复杂的攻击）。

The first benefit is automatic. It is guaranteed by the cryptographic protocol and cannot be stripped away (except by very complex attacks on security holes that are usually fixed very quickly).

第二个好处并不严格技术优势：这是信任的问题。服务器使用证书将其公钥（授予第一个安全组件）与其自己的标识链接起来。这些公钥证书由称为证书颁发机构（CA）的用户信任机构签名。

The second benefit is not strictly a technical benefit: it is a matter of trust. Servers use certificates to link their public key (which grants the first security component) with their own identity. Those public-key certificates are signed by user-trusted institutions called certificate authorities (CAs).

当您尝试连接到<$ c时$ c> bob.com ，该网站为您提供了执行安全通信的公钥。你持怀疑态度并说：当然，这张公钥会让我安全地跟你说话，但我怎么知道你真的 bob.com ？然后，服务器会为您提供 CA签名证书，其中包含：

When you try to connect to bob.com, the site gives you a public key to perform secure communication. You're skeptical and say, "Sure, this public key will allow me to talk to you securely, but how do I know you're really bob.com?" The server then gives you a CA-signed certificate that says:

我们，VeriSign证书颁发机构，谁在我们的调查中被广泛信任，特此证明以下公钥真正属于 bob.com ：

公钥： ZGdlZGhydGhyaHJ0eWp5cmo ...

可验证签名，

VeriSign

有许多主要的证书颁发机构被广泛信任（通过操作系统和浏览器）来发布当且仅当他们已经可靠地验证公钥确实属于域名时才签名的证书。由于您的操作系统已经信任这些签名，我们可以在不进行任何确认的情况下使用它们。

There are many major certificate authorities who are widely trusted (by operating systems and browsers) to issue a signed certificate if and only if they have reliably verified that a public key really does belong to a domain name. Because your OS already trusts these signatures, we can use them without any confirmation.

当您使用自签名证书时，没有可信任的CA已经验证您的证书确实属于到你的域名。任何人都可以制作一份文件说：

When you use a self-signed certificate, no trusted CA has verified that your cert really belongs to your domain name. Anyone can produce a document that says:

嘿，伙计，这是100％绝对是 bob的公钥.com ：

公钥： WGdoZmpodHlqa2p1aXl1eWk ...

请相信我们，写这封信的人，好吗？我们绝对肯定这是关键。写这篇文章的人是那些运行 bob.com 的人。我们保证。

Just trust us, the guys who wrote this note, okay? We're DEFINITELY sure that's the key. The guys who wrote this note are the guys who run bob.com. We promise.

签名，

撰写本笔记的人

这里没有可信任的签名。用户必须决定是否希望接受公钥真正属于 bob.com 的证书认证。

This doesn't have a trusted signature on it. The user must decide if they wish to accept the certificate's attestation that the public key really belongs to bob.com.

做出有意义的决定是一个困难的过程 - 您需要检查证书并在某处找到公钥的预先存在的可信记录（或联系站点管理员或技术支持代表）。实际上，您需要信任证书来自某处，因为它不是来自主要证书颁发机构的可信签名。

Making this decision meaningfully is a difficult process -- you need to inspect the certificate and find a preexisting trusted record of the public key somewhere (or contact a site administrator or help desk representative). In effect, you need have your trust of the certificate come from somewhere, because it isn't coming from the trusted signature of a major certificate authority.

允许JavaScript自动确定信任是没有意义的。整点是用户必须决定证书是否值得信任，然后对系统的证书存储进行适当的修改。

Allowing JavaScript to automatically make this determination of trust makes no sense. The entire point is that the user must decide whether or not the certificate is trustworthy and then make the appropriate modifications to the system's certificate store.

这个可以假设为Ajax请求完成，但它不会很漂亮。您需要向用户显示一个浏览器UI屏幕，询问用户是否希望信任脚本尝试访问的任何域的自签名证书。除了对浏览体验非常具有破坏性之外，这可能会造成危险的混乱：如果我在 example.com ，并且突然（由于脚本的操作，我没有不知道。我被要求信任 bob.com 的证书，我可能完全基于我对 example.com的信任而接受它。

This could hypothetically be done for Ajax requests, but it wouldn't be pretty. You'd need to show the user a browser-UI screen asking if the user wants to trust the self-signed certificate for whatever domain the script is trying to access. Aside from being very disruptive to the browsing experience, this could be dangerously confusing: if I'm on example.com, and suddenly (due to the actions of a script I didn't know about) I'm asked to trust a certificate for bob.com, I might accept it purely based on my trust of example.com.

将证书添加到系统的可信证书列表中，或者让系统已经信任的CA对证书进行签名。

Either add the certificate to your systems' trusted certificate list, or get it signed by a CA that is already trusted by your systems.

这篇关于ERR_INSECURE_RESPONSE在Javascript中处理提示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！