Questions tagged «chrome»

我有一个HAProxy /隧道服务器，可为AWS上的站点处理SSL。在测试过程中，我在此服务器上创建了一个自签名证书，并使用Chrome从我的桌面上将其命中，以测试通道是否正常工作。 现在，我已在该服务器上安装了合法证书。当我从Chrome中的计算机访问网站时，会引发以下错误： 错误113（net :: ERR_SSL_VERSION_OR_CIPHER_MISMATCH）：未知错误。 我的猜测是Chrome缓存了自签名证书的密钥，但它与合法证书的密钥不匹配。该站点可在我的计算机上的所有其他浏览器中使用，因此这只是一个Chrome问题。 一个有趣的注意事项：从隐身会话（Ctrl+ Shift+ N）进入页面时，它可以正常工作。因此，这显然是某种缓存内容。 我做了所有我能想到的事情（转储了缓存，从“管理证书”对话框的“个人和其他人”页面中删除了证书，Ctrl+ F5等）。 我的机器是Windows 7 x64。Chrome版本：12.0.742.91。 在Google Chrome浏览器帮助表格上，有一个听起来像是同一问题的描述；但是，找不到解决方案。 更新：今天似乎已经“修复”了。我讨厌这样的问题。我仍然不知道是什么原因造成的，或者它是如何自行解决的。大概是缓存的证书过期了，但是我仍然很想知道此信息的存储位置以及如何对其进行验证。

72 ssl  cache  chrome 

我注意到最近几天来自工作站的流量异常。我看到HEAD请求发送到随机字符的URL，通常在一秒钟内出现三到四个，这些请求似乎来自我的Chrome浏览器。每天仅重复三到四次请求，但我尚未确定特定的模式。每个请求的URL字符都不同。 这是Fiddler 2记录的请求示例： HEAD http://xqwvykjfei/ HTTP/1.1 Host: xqwvykjfei Proxy-Connection: keep-alive Content-Length: 0 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 对此请求的响应如下： HTTP/1.1 502 Fiddler - DNS Lookup Failed Content-Type: text/html Connection: close Timestamp: 08:15:45.283 Fiddler: DNS Lookup for …

55 http  malware  chrome 

从Chrome 58开始，它不再接受依赖于Common Name以下各项的自签名证书：https : //productforums.google.com/forum/#! topic/chrome/zVo3M8CgKzQ;context-place = topicsearchin/chrome/category $ 3ACanary％7Csort：相关性％7Cspell：假 相反，它需要使用Subject Alt Name。之前，我一直在遵循有关如何生成自签名证书的指南：https : //devcenter.heroku.com/articles/ssl-certificate-self，该方法非常有效，因为我需要在执行操作时使用server.crt和server.key文件。现在，我需要生成新的证书，其中包括SAN我所做的所有尝试都不适用于Chrome 58。 这是我所做的： 我按照上述Heroku文章中的步骤生成了密钥。然后，我编写了一个新的OpenSSL配置文件： [ req ] default_bits = 2048 distinguished_name = req_distinguished_name req_extensions = san extensions = san [ req_distinguished_name ] countryName = US stateOrProvinceName = Massachusetts localityName = Boston organizationName = MyCompany [ san …

52 ssl  ssl-certificate  openssl  chrome 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使其成为服务器故障的主题。 10个月前关闭。 我在测试环境中在Docker中运行chromedriver + chrome。 在最新的CoreOS升级之前，一切工作正常。 这些是似乎有效的版本： VERSION=1185.5.0 VERSION_ID=1185.5.0 BUILD_ID=2016-12-07-0937 这是导致chrome转储的新版本： VERSION=1235.4.0 VERSION_ID=1235.4.0 BUILD_ID=2017-01-04-0450 查看变化，看来docker已从1.11.x升级到1.12.x，这打破了setns()容器内部的调用。setns()被Chrome浏览器用来创建名称空间。 这是示例输出： jsosic-coreos-test-20161207 ~ # docker --version Docker version 1.11.2, build bac3bae 从此盒子上的一个容器内部： [root@2939f21ecfaa /]# /opt/google/chrome/google-chrome [57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display: 这是新版本破解它的方式： jsosic-coreos-test-2017-01-04 ~ # docker --version Docker version 1.12.3, build 34a2ead [root@13ab34c36c82 /]# …

11 permissions  docker  chrome  namespaces 

对于网站scirra.com（单击以获取SSL Labs服务器测试结果），Google Chrome浏览器报告以下图标： 这是一种EV SSL，在Firefox和Internet Explorer中似乎可以正常工作，但在Chrome中却不能。这是什么原因呢？

9 ssl  chrome  ssl-certificate