有没有办法使用 JavaScript 获取 SSL 证书详细信息？
我想收集特定网站上 SSL 证书的某些详细信息。我知道在 Linux/MacOSX 上使用 openssl 工具很简单。但是 JavaScript 中可能有相同或相似的情况吗？
据我所知，浏览器处理套接字连接，并且 SSL 握手发生在任何一方发送数据之前。但是，在 XMLHTTPRequest 中，我想知道是否可以将这些详细信息作为某种响应代码等获取？
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?
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这些信息根本不会暴露给 JavaScript，它很少被使用（当然从来没有，因为它不可用，但它会很少被使用），以至于它被认为不够重要，无法添加到我想 JavaScript 对象模型...对于任何很少使用的功能来说都是一样的。
当然，出于安全原因，它也可能被排除在外......我目前没有足够的创造力来想出一个，但我确信那里也有一个漏洞。
This information simply isn't exposed to javascript, it is so rarely used (well never since it isn't available, but it would be 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.
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.
该证书不是 DOM 的一部分，所以不，这是不可能的。对不起！
The certificate isn't part of the DOM, so no, this won't be possible. Sorry!
不，不可能。
可以通过 javascript 检测当前正在查看的页面是否通过 SSL 连接 (document.location.protocol=="https:")，但仅此而已。
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.
目前的JS语言标准并没有暴露证书信息；除此之外，这可能取决于您如何使用 JavaScript，如果您希望最终用户的浏览器公开证书信息，那么这将是一个真正的问题，因为您需要获得最低的 FF、Chrome、Safari、IE ，边缘，...暴露它。
但是，正如信息安全帖子<中提到的/a>，这对于这些浏览器来说并不是一个真正理想的选择，因为它会导致网站开发人员编写代码错误地信任用户端凭据。
与其说这是阻止 JavaScript 访问浏览器当前 SSL 证书信息的可见性安全风险，不如说是第四堵墙安全风险，JS 开发人员必须意识到“用户接受的”证书不一定是提供的网站。 HTML 页面确实不应该使用客户端代码处理安全问题，而应该能够依赖安全层来正确完成其工作。 （我完全可以理解想要检查安全层，但是您在顶层所做的任何管理工作都只是肤浅的或对整个生物圈的改造）
因为让我们暂时假设 javascript 确实提供了一种方法如果 Bob 已经信任 Mallory，因为他的安全性已被破坏，则无法阻止以下交换：
办公室工作人员 Bob 位于 Mega Corp. 防火墙的一侧，IT Mallory 负责防火墙在本地传递进出公司的流量，并且 Web Host Alice 的精彩网站位于 WWW 上。
（注意：我没有解决您在服务器端运行 JS 的情况，那么这取决于您使用什么程序来运行 JS 代码。）
Edit 4/4/2018 -- While the above is not wrong it's more from the perspective of embedded and linked JS than it is about the `XMLHTTPRequest` JS object; moreover quite possibly the strongest argument to be made against sharing PKI details with `XMLHTTPRequest` is as follows:
在 HTTP 部分和HTTPS 协议的 S 部分。 JavaScript 及其
XMLHTTPRequest对象驻留在该行的 HTTP（应用层）一侧，而整个证书交换过程驻留在该行的 S（trans/sec 层）一侧。为了保持安全端的原子性（可热插拔），其内部工作不能跨线暴露给应用程序端；因为可能有一天，传输/安全层不再使用 PKI 证书来促进其安全通信服务，并且当那一天到来时，没有人需要重写任何依赖于这些证书中包含的详细信息来处理的现有 JS 代码。随着 www 社区慢慢采用他们最喜欢的任何新安全层风格引起的传播浪潮。话虽这么说，安全方面似乎也在进行法人实体审查——至少在某些情况下，例如 EV 证书——，而且在我看来，这是 RFC7230 第 2.7.2 节 表示它不会重新定义
https 的包含一个可选的合法性，安全层在验证与其通信的 URL 不仅是正确的端点而且当前处于预期业务关系的控制之下时将使用该合法性。authority-URIThe 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.
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)
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:
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.
(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.)
Edit 4/4/2018 -- While the above is not wrong it's more from the perspective of embedded and linked JS than it is about the `XMLHTTPRequest` JS object; moreover quite possibly the strongest argument to be made against sharing PKI details with `XMLHTTPRequest` is as follows:
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.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.2 that it does not redefine the
authorityof thehttps-URIto include an optionallegalentitythat 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.