Javascript 中的 ERR_INSECURE_RESPONSE 处理技巧

ERR_INSECURE_RESPONSE handing tips in Javascript

提问by Pradeep Simha

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:

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

Failed to load resource: net::ERR_INSECURE_RESPONSE

无法加载资源：net::ERR_INSECURE_RESPONSE

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?

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

Note: We are testing all these in chrome browser

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

回答by apsillers

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.

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

HTTPS provides two security benefits:

HTTPS 提供了两个安全优势：

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 tois really who they claim to be (e.g., when Alice talks to bob.comshe's knows it's really the server she knows as bob.comand not an impostor)

1. 您知道您与正在与之交谈的人之间的通信渠道是安全的（例如，当 Alice 与 Bob 交谈时，她知道没有其他人可以听到）
2. 你知道你在和谁说话，他们声称是谁（例如，当爱丽丝和bob.com她说话时，她知道这真的是她认识的服务器，bob.com而不是冒名顶替者）

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).

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

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).

第二个好处不是严格意义上的技术好处：它是一个信任问题。服务器使用证书将他们的公钥（授予第一个安全组件）与他们自己的身份联系起来。这些公钥证书由称为证书颁发机构(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 reallybob.com?" The server then gives you a CA-signed certificatethat says:

当您尝试连接到 时bob.com，该站点会为您提供一个公钥来执行安全通信。你持怀疑态度说：“当然，这个公钥可以让我安全地与你交谈，但我怎么知道你是真的bob.com？” 然后服务器会给你一个CA 签名的证书，上面写着：

We, the VeriSign certificate authority, who are widely trusted to be thorough in our investigations, hereby attest that the following public key really does truly belong to bob.com:

Public key: ZGdlZGhydGhyaHJ0eWp5cmo...

Verifiably signed,

VeriSign

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

公钥： ZGdlZGhydGhyaHJ0eWp5cmo...

经核实签署，

威瑞信

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.

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

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:

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

Hey, man, this is 100% definitely the public key for bob.com:

Public key: WGdoZmpodHlqa2p1aXl1eWk...

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.

Signed,

The guys who wrote this note

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

公钥： WGdoZmpodHlqa2p1aXl1eWk...

相信我们，写这篇笔记的人，好吗？我们绝对确定这是关键。写这篇笔记的人是那些跑的人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.

这上面没有受信任的签名。用户必须决定他们是否希望接受公钥确实属于的证书证明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.

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

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

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

This couldhypothetically 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.

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

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

要么将证书添加到系统的受信任证书列表中，要么由系统已经信任的 CA 对其进行签名。

回答by Saruva

Adding the trusted certificate should be enough if all the AJAX calls are made in the same domain, if they're not of the same domain, using JSONP to get the data with AJAX you wouldn't get the error.

如果所有 AJAX 调用都在同一个域中进行，添加受信任的证书应该就足够了，如果它们不在同一个域中，则使用 JSONP 通过 AJAX 获取数据就不会出现错误。

If you would like to know about JSONP, here is an useful link: http://www.sitepoint.com/jsonp-examples/

如果您想了解 JSONP，这里有一个有用的链接：http: //www.sitepoint.com/jsonp-examples/