有没有办法使用 JavaScript 获取 SSL 证书详细信息？

Is there a way to get SSL certificate details using JavaScript?

提问by shaond

I'd like to gather certain details of an SSL certificate on a particular web-site. I know this is straightforward using the openssl tool on Linux/MacOSX. However is the same or similar possible in JavaScript?

我想在特定网站上收集 SSL 证书的某些详细信息。我知道在 Linux/MacOSX 上使用 openssl 工具很简单。但是在 JavaScript 中是否可能相同或相似？

I understand that the browser handles socket connections and that the SSL handshake occurs prior to any party sending data. However in an XMLHTTPRequest, I'd like to know if its possible to get these details as some sort of response code etc?

我了解浏览器处理套接字连接，并且 SSL 握手发生在任何一方发送数据之前。但是，在 XMLHTTPRequest 中，我想知道是否可以将这些详细信息作为某种响应代码等获取？

采纳答案by Nick Craver

This information simply isn't exposed to javascript, it is so rarely used (well never since it isn't available, but it wouldbe rarely used) that it wasn't deemed important enough to add to the javascript object model I suppose...same for any very rarely used feature left out of anything.

这些信息根本没有暴露于JavaScript中，就这样很少使用（也从来没有因为它是不可用的，但它会很少使用），它不被认为足够重要添加到JavaScript对象模型，我想。 ..对于任何很少使用的功能都一样。

Of course, it could have also been left out for security reasons...I'm not creative enough to come up with one at the moment, but I'm sure there's an exploit to be had there as well.

当然，出于安全原因，它也可能被排除在外……我目前没有足够的创造力来提出一个，但我相信那里也有一个漏洞利用。

回答by John Feminella

The certificate isn't part of the DOM, so no, this won't be possible. Sorry!

证书不是 DOM 的一部分，所以不，这是不可能的。对不起！

回答by Gregor y

The current JS language standard does not expose certificate information; beyond that It probably depends on how you're using JavaScript, if you're expecting the end user's Browser to expose certificate information then it's going to be really problematic because you'd need to get at the minimum FF, Chrome, Safari, IE, Edge, ... to expose it.

当前的 JS 语言标准没有公开证书信息；除此之外，这可能取决于您如何使用 JavaScript，如果您希望最终用户的浏览器公开证书信息，那么这将是非常有问题的，因为您需要获得最低限度的 FF、Chrome、Safari、IE , Edge, ... 暴露它。

However, as mentioned on this Information Security post, this is not really a desirable option for these browsers to implement, as it would allow a situation where a website developer could write code to mistakenly trust user side credentials.

然而，正如这篇信息安全帖子中所提到的，这对于这些浏览器来说并不是一个真正理想的实现方式，因为它会导致网站开发人员编写代码来错误地信任用户端凭据的情况。

It's not so much a visibility security risk that prevents javascript from accessing the browser's current SSL Certificate info, but more of a fourth wall barrier security risk where the JS developer must be aware that the "user-accepted" certificate is not necessarily the one that the website provided. The HTML page really shouldn't be handling the security issues with client side code, but instead it should be able to depend on the security layer to do it's job properly. (I can totally understand wanting to checkup on the security layer, but any managerial work you do at the top layer is just going to be either superficial or a reworking of the entire biosphere)

阻止javascript访问浏览器当前SSL证书信息的可见性安全风险与其说是可见性安全风险，不如说是第四道屏障安全风险，其中JS开发人员必须意识到“用户接受”的证书不一定是提供的网站。HTML 页面真的不应该处理客户端代码的安全问题，而是应该能够依赖安全层来正确地完成它的工作。（我完全可以理解想要检查安全层，但你在顶层所做的任何管理工作要么是肤浅的，要么是对整个生物圈的改造）

Because let's assume for a moment that javascript did provide a way to work with the certificate, then when Bob already trusts Mallory because his security is broken there is no way of stopping the following exchange:

因为让我们暂时假设 javascript 确实提供了一种使用证书的方法，那么当 Bob 已经信任 Mallory 因为他的安全性被破坏时，就无法停止以下交换：

Office Worker Bob is on one side of the great firewall of Mega Corp., IT Mallory is in charge of the firewall passing traffic in and out of the company locally, and Web Host Alice's awesome website is out on the WWW.

上班族 Bob 位于 Mega Corp. 伟大防火墙的一侧，IT Mallory 负责将流量传入和传出本地公司的防火墙，而 Web Host Alice 的超棒网站在 WWW 上。

1. By Mega Corp. company policy Bob is setup to just accept what Mallory has to say at face value.
2. Bob who would like to visit Alice's site, but has no direct outside access, tries to establish a secure connection through the firewall by holding up his certificate(Eg:"I hereby declare I am Bob") and asks Alice in a really convoluted way, "what certificate did I send to you?"
3. Mallory gets Bob's request, but instead passes on her own(Eg:"Uh, Bob says it's ok for me to read his webmail"), and even though Mallory doesn't understand Bob's convoluted question she still repeats it to Alice, "akdvyfenwythnwerhy?".
4. Alice does some math and figures out that "akdvyfenwythnwerhy?" is asking "what certificate did I send you?" and answers back to Mallory with what she sees("Hi Bob this is Alice you said: Uh, Bob says it's ok for me to read his webmail").
5. Mallory does some math, has an ah ha moment "akdvyfenwythnwerhy?=what certificate did I send to you?", and answers Bob's question on behalf of Alice("Hi Bob this is Alice(Mallory) you said: I hereby declare I am Bob").
6. Bob believes life is good and continues on to read his webmail, because by company policy he knows Mallory would never lie to him.
7. Mallory now able to read both sides of the conversation passes on Bob's request to read his webmail to Alice.
8. Alice gets Bob's request and says hey wait a minute Bob I need you to run this JS code to prove you know you're talking to Alice.
9. Mallory gets the code, runs it, and sends the results stating that she knows she's talking to Alice back to Alice.
10. Alice says, good enough for me here's your webmail.
11. Mallory reads Bob's webmail before passing it on to Bob, and everyone is blissfully happy.

1. 根据 Mega Corp. 公司的政策，鲍勃只接受马洛里所说的表面价值。
2. Bob 想访问 Alice 的站点，但没有直接的外部访问权限，他试图通过持有他的证书（例如：“我在此声明我是 Bob”）来通过防火墙建立安全连接，并以一种非常令人费解的方式询问 Alice ，“我给你寄了什么证明？”
3. Mallory 得到了 Bob 的请求，但转而传递了她自己的请求（例如：“呃，Bob 说我可以阅读他的网络邮件”），即使 Mallory 不理解 Bob 令人费解的问题，她仍然向 Alice 重复，“akdvyfenwythnwerhy ？”。
4. 爱丽丝做了一些数学运算并计算出“akdvyfenwythnwerhy？” 是问“我给你寄了什么证书？” 并用她所看到的回答马洛里（“嗨，鲍勃，这是爱丽丝，你说：呃，鲍勃说我可以阅读他的网络邮件”）。
5. Mallory 做了一些数学运算，有一个啊哈时刻“akdvyfenwythnwerhy？=我给你发送了什么证书？”，并代表 Alice 回答 Bob 的问题（“嗨，Bob，这是 Alice（Mallory），你说：我在此声明我是鲍勃”）。
6. Bob 相信生活是美好的，并继续阅读他的网络邮件，因为根据公司的政策，他知道 Mallory 永远不会对他撒谎。
7. Mallory 现在能够阅读对话的双方，将 Bob 阅读他的网络邮件的请求传递给 Alice。
8. Alice 收到 Bob 的请求并说嘿，等一下 Bob 我需要你运行这个 JS 代码来证明你知道你正在和 Alice 交谈。
9. Mallory 获取代码，运行它，然后将结果发送给 Alice，说明她知道她正在与 Alice 通话。
10. 爱丽丝说，这对我来说已经足够了，这是您的网络邮件。
11. Mallory 在将邮件传递给 Bob 之前阅读了 Bob 的网络邮件，每个人都非常高兴。

(Note: I did not address the case where you're running JS server-side, then it would depend on what program you're using to run your JS code.)

（注意：我没有解决您在服务器端运行 JS 的情况，这取决于您使用什么程序来运行您的 JS 代码。）

---

---

编辑 2018 年 4 月 4 日——虽然上述内容没有错，但更多的是从嵌入和链接的 JS 的角度来看，而不是关于XMLHTTPRequestXMLHTTPRequestJS 对象；此外，反对共享 PKI 详细信息的最有力论据很可能XMLHTTPRequestXMLHTTPRequest如下：

There needs to remain a strong dividing line between the HTTP portion and the S portion of the HTTPS protocol. JavaScript and it's XMLHTTPRequestobject reside on the HTTP(app layer) side of that line, while the whole certificate exchange process resides on the S(trans/sec layer) side of that line. In order to keep the security side atomic(hot-swappable) its internal workings cannot be exposed across the line to the application side; because there may come a day when the transport/security layer no longer uses PKI certificates to facilitate its secure communication service, and when that day comes no one would need to rewrite any existing JS code that was relying on details contained within those certificates to deal with the propagation wave caused by the www community slowly adopting their favorite flavor of any new security layer.

HTTPS 协议的 HTTP 部分和 S 部分之间需要保持一个强有力的分界线。JavaScript 及其XMLHTTPRequest对象驻留在该行的 HTTP（应用程序层）端，而整个证书交换过程驻留在该行的 S（传输/秒层）端。为了保持安全端的原子性（热插拔），其内部工作不能跨线路暴露给应用程序端；因为可能有一天，传输/安全层不再使用 PKI 证书来促进其安全通信服务，而当那一天到来时，没有人需要重写任何依赖这些证书中包含的详细信息来处理的现有 JS 代码随着 www 社区引起的传播波慢慢采用他们最喜欢的任何新安全层的风格。

That being said, the security side does appear to also be doing legal entity vetting --at least in some cases like EV certificates--, and it is IMO a short coming of RFC7230 section 2.7.2that it does not redefine the authorityof the https-URIto include an optional legalentitythat the security layer would use when verifying the url it is communicating with is not only the proper end point but also currently under control of the intended business relation.

话虽这么说，在安全性方面确实出现了在某些情况下还可以做法律实体--at至少像EV certificates--，这是IMO来的短RFC7230第2.7.2节，它并没有重新定义authority的https-URI包含legalentity安全层在验证与之通信的 url 时将使用的可选内容不仅是正确的端点，而且当前处于预期业务关系的控制之下。

authority     = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ]
legalentity   = *( unreserved / pct-encoded / sub-delims )

回答by Sean

Nope, not possible.

不，不可能。

It is possible to detect via javascript whether the current page being viewed is over an SSL connection (document.location.protocol=="https:"), but that's about it.

可以通过 javascript 检测正在查看的当前页面是否通过 SSL 连接（document.location.protocol=="https:"），但仅此而已。