在我们的nginx错误日志中，我们发现在过去几天里有一些类似这个错误： /var/log/nginx/error.log.2.gz:2017/01/30 16:11:46 [crit] 13114#13114: *139338 SSL_do_handshake() failed (SSL: error:14094459:SSL routines:SSL3_READ_BYTES:tlsv1 bad certificate status response:SSL alert number 113) while SSL handshaking, client: XXXX, server: 0.0.0.0:443 我们使用让我们encryption这个证书。 我们不能自己再现这个问题，到目前为止，我们还没有能够从客户端得到任何可能导致这个问题的信息。 RFC 6066说这与OSCP有关： 在“CertificateStatus”消息中请求OCSP响应并接收到OCSP响应的客户端必须检查OCSP响应，并在响应不满足bad_certificate_status_response（113）警报的情况下中止握手。 这个警报总是致命的。 我们在我们的nginxconfiguration中有这个： # OCSP Stapling # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; 域名从SSL实验室获得A +，我们不能自己复制这个。 什么可能导致这个错误？ 编辑 ：对于在过去几天发生的3次，只有一个在访问日志中留下了IP地址的条目： […]
我们有在线购物网站。 当我要结帐页面，我得到这样的错误“错误：14094410：SSL例程：SSL3_READ_BYTES：sslv3警报握手失败（35）” 从Apache的错误日志，我可以看到一些尝试连接到api.paypal.com。 这是我的Apache错误日志的一部分 * About to connect() to api.paypal.com port 443 (#0) * Trying 66.211.168.123… * connected * Connected to api.paypal.com (66.211.168.123) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure * Closing connection #0 当我试图连接到api.paypal.com使用curl我得到这样的错误 curl -iv https://api.paypal.com/ * About to connect() […]
我运行一个debian压缩标准的Apache安装（2.2），并使用SSLClientCertificates来授权用户。 这工作很好迄今。 但是我们注意到一些并行请求的缓慢，并试图检查我的SSLSessionCache是否正在工作。 所以我检查了我的本地主机/服务器状态，它是这样读的： SSL/TLS Session Cache Status: cache type: SHMCB, shared memory: 512000 bytes, current sessions: 0 subcaches: 32, indexes per subcache: 133 index usage: 0%, cache usage: 0% total sessions stored since starting: 0 total sessions expired since starting: 0 total (pre-expiry) sessions scrolled out of the cache: 0 total retrieves since starting: […]
我试图在我的一台服务器上testingSSL连接。 服务器位于LB后面，因此它正在侦听端口8090上的SSL连接。 我使用–resolve选项来testing与侦听端口443的LB交谈。 curl –resolve 'myservice.com:443:1.1.1.1' 'https://myservice.com' 但是当我这样做： curl –resolve 'myservice.com:8090:2.2.2.2' 'https://myservice.com:8090' curl只是忽略端口，并与443.当然，这导致DNScaching错过，我最终使用公共DNS IP … * Added myservice.com:8090:2.2.2.2 to DNS cache * About to connect() to myservice.com port 443 (#0) * Trying 3.3.3.3… * Connected to myservice.com (3.3.3.3) port 443 (#0) 如何强制curl使用端口8090进行SSL连接？ 谢谢。
我们使用F5来执行负载平衡。 当使用SSL桥接而不是终止时，我们通常在前端使用通配符，在HTTPS后端使用常规的SSL证书。 然而，有些同事相信，对于像MS Exchange这样的应用，我们必须在后端和负载平衡器中使用相同的私钥。 我无法围绕后端如何检查负载均衡器使用的私钥。 我查了F5的文档，但是找不到任何相关的东西。 有人能帮我理解吗？ 更新1：我开始强烈怀疑，这是一个虚假陈述，尽pipe有几个同事的帐户实际上发生了什么。 这种怀疑现在已被其他人重申。 当我find决定性的东西时我会更新。 如果有其他人有想法，请提交。 更新2：对于VMware Horizon，我发现了一篇KB文章，解释了证书不匹配时收到的错误 。 我可以从这里得出结论：Horizon正在做的是通过比较协议中的指纹来实现自己的检查吗？
我为我公司的一些内部服务创build了一个自签名的根证书颁发机构，我自己configuration了自己（主要通过HTTPS服务）。 然后，我为这些服务创build了证书，并使用此CA签名。 现在，我想将x509扩展（CRL分发点）添加到根CA，而不会使从此CA发出的现有服务器证书失效。 这可能吗？ 我的直觉是“是”，因为据我所知，访问相应的私钥对于证书身份的“完全授权”是必要和充分的。 也就是说，除非在生成（有可能）的情况下将某种随机数与公钥一起并入证书中。 我对SSL证书pipe理还是比较新的，但是我想（我）理解标准信任链的基础知识。 我也很熟悉其他PKIencryption的基本用法：我pipe理SSH密钥并使用GPG进行签名和encryption。 我学习计算机科学，虽然我只是一个自学成才的密码学。 我从来没有为原来的IIRC做过CSR（我认为这是openssl req -new -x509的直接输出）。 当然，我仍然有原始的CA私钥，使用它我能够将原始证书“反向”成证书签名请求： openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key 我希望这将有效地“提取”上面提到的nonce，并允许我重新创build证书，但是这次使用crlDistributionPoints字段，因此所有使用原始CA签名的证书仍然会validation这个新的CA，客户端会从该字段中指定的HTTP URL检索我的（当前为空）CRL文件。 所以我做了一个扩展configuration文件ext.conf ： [ cert_ext ] subjectKeyIdentifier=hash crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl 而且我从CSR生成了新版本的根CA： openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem 现在，当我用openssl x509 -text -in MyNewCA.pem | less查看证书时 openssl x509 […]
我想弄清楚如何设置haproxy和SSL反向代理服务器的SSL场，我正在寻找一些一般性的build议： 是否有可能满足以下所有条件： 负载平衡请求针对SSL场，并有故障转移，所以多个SSL盒将成为可能（也许haproxy的sslcheck将有助于这一点）。 获取具有实际客户端IP地址的HTTP日志。 没有TProxy要求 如果所有这三个都不可能，我想知道什么是权衡。 现在我正在考虑类似下面的内容，但这可能会改变： Haproxy 443 TCP Proxy Frontend – > SSL代理（也许Nginx）在高端口 – > Haproxy HTTP前端 – > Web服务器 我意识到我可以跳过第二跳回haproxy，但HAproxy中的一切的单一视angular可能是好的。 另外如果我必须使用TProxy，也许回到haproxy从SSL农场将使路由更简单？ 参考文献： http://haproxy.1wt.eu/download/1.5/doc/configuration.txt http://1wt.eu/articles/2006_lb/index_05.html
我试图在一系列CentOS系统上为我的内部证书服务器安装一个证书，而且我发现这个文档几乎不存在。 我的最终目标是能够对内部安全服务器使用git ， curl和其他方法，而不会出错。 在Ubuntu上很简单，你把证书扔到一个文件夹中，然后运行一个命令来生成一系列的链接，将CA证书添加到证书path中。 我不能在我的生活中find如何在CentOS上做这些事情。大量信息可用于信任随机证书。 （也就是说，在/etc/pki/tls/certs创build一个符号链接到PEM编码的证书文件中，并用证书的散列来命名。我的CA没有工作，因为上述应用程序仍然无法validation证书由CA签字）。 你如何在CentOS系统上安装一个新的根CA？
我一直在试图安装我的LetsEncrypt生成的证书到我的rabbitmq服务器，但没有运气。 为了testing事情与出局必须反对权限问题，我已经复制了pem文件 /etc/letsencrypt/live/<domain>/ 到我的主目录。 我也从我find它的位置复制cacert.pem文件到我的主目录： /home/<user>/.local/share/letsencrypt/lib/python2.7/site-packages/requests/cacert.pem 我决定首先尝试通过编辑要添加的rabbitmq.config来在pipe理插件上安装证书 {rabbitmq_management, [%% Pre-Load schema definitions from the following JSON file. See %% http://www.rabbitmq.com/management.html#load-definitions %% %% {load_definitions, "/path/to/schema.json"}, %% Log all requests to the management HTTP API to a file. %% %% {http_log_dir, "/path/to/access.log"}, %% Change the port on which the HTTP listener listens, %% specifying an interface for […]
为了解决问题，我需要查看通过SMTP发送到我的sendmail服务器时的电子邮件的样子。 上游服务器需要SMTP连接才能使用STARTTLS，因此数据包捕获仅显示encryption的数据。 有没有办法使用wireshark解密传输，看看？ 当然假设我有我的sendmail服务器上使用的私钥？ 我看到几个可以在线参考的wireshark中的RSA key listsfunction（例如： https ： //support.citrix.com/article/CTX116557 ）。 但是，这似乎还没有为我工作。 这与前向保密有关吗？ 我可以不在新的协议/密码上做这个吗？