LetsEncrypt：连接中未知的SSL协议错误

我有一个LE证书的主机，它在浏览器中运行良好，但我仍然无法使用curl ， openssl ， wget ， POST （libwww-perl）进行连接：

curl

 # curl -v -3 https://example.com/ * Hostname was NOT found in DNS cache * Trying 123.123.123.123... * Connected to example.com (123.123.123.123) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to example.com:443 * Closing connection 0

OpenSSL的

 # openssl s_client -connect example.com:443 CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 295 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---

wget的

 # wget --post-data "key=val" -vvv https://example.com/ --2016-05-11 11:19:01-- https://example.com/ Resolving example.com (example.com)... 123.123.123.123 Connecting to example.com (example.com)|123.123.123.123|:443... connected. Unable to establish SSL connection.

POST

 # echo 'key=val' | POST https://example.com:443 Can't connect to example.com:443 LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error SSL wants a read first at /usr/share/perl5/LWP/Protocol/http.pm line 41, <STDIN> line 1.

虚拟主机configuration：

 <VirtualHost *:443> ServerName example.com SSLEngine On SSLProtocol ALL -SSLv2 -SSLv3 SSLHonorCipherOrder On SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS SSLVerifyDepth 10 SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/example.com/fullchain.pem DocumentRoot "/var/www/" </VirtualHost>

我认为你的问题是DNSSEC相关的。该区域存在DSlogging：

 [me@risby ~]$ dig ds codestronaut.com [...] ;; ANSWER SECTION: codestronaut.com. 86363 IN DS 19465 8 1 42AFC90FE0A61D3993051C55B6C4C35518713921

但chat的Alogging是无符号的：

 [me@risby ~]$ dig +dnssec +trace chat.codestronaut.com [...] codestronaut.com. 172800 IN NS dns1.yandex.net. codestronaut.com. 172800 IN NS dns2.yandex.net. codestronaut.com. 86400 IN DS 19465 8 1 42AFC90FE0A61D3993051C55B6C4C35518713921 codestronaut.com. 86400 IN RRSIG DS 8 2 86400 20160517050727 20160510035727 34745 com. Xk/mK5Y8LigJyP+iPF9arhZXKmsDvslfigom/7BZ2orIKHFGAX8/Q9eE O4rRCZPQD82WBssFHf/jcYSUiZrF/j6Ovq4sPbOJbjPUUoHlkOb8uGe/ 3erv6snM8SKVu8eSaE42cj8efvNRZR4S1MMesD5HGG1gMzjQLkTvHiEN wmE= ;; Received 329 bytes from 192.54.112.30#53(h.gtld-servers.net) in 18 ms chat.codestronaut.com. 21600 IN A 95.158.40.23 ;; Received 66 bytes from 2a02:6b8::213#53(dns1.yandex.net) in 66 ms

请注意RRSIG缺lessRRSIGlogging。这会导致DNS查找在某些平台上失败：

 [me@risby ~]$ curl https://chat.codestronaut.com curl: (6) Could not resolve host: chat.codestronaut.com

我不认为有很大的可能性，直到你修复你的DNS才能可靠地工作。要么您的注册商停止发布该区域的DSlogging，要么正确地签署您的区域。我并不是说这是你唯一的问题，但是有一个工作的DNS几乎是所有其他事情的先决条件，包括debugging。

编辑：你说你已经禁用了DNSSEC，但这个改变还没有传播（这可能需要一天的时间，因为你的旧DSlogging中的TTL是86400s）。使用DNSSEC盲人客户端，我不能重现您报告的问题，但我注意到您正在该系统上运行SNI（即，有几个SSL证书可用，包括chat.codestronaut.com和panel.codestronaut.com ）。

curl -v -3显式不支持SNI（因为SNI是TLS的扩展，因此在SSLv3中不可用）。一旦被SNI警告， openssl s_client可以正常工作：

 [me@lory tmp]$ openssl s_client -connect chat.codestronaut.com:443 -servername chat.codestronaut.com [...] Certificate chain 0 s:/CN=chat.codestronaut.com i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1 1 s:/CN=chat.codestronaut.com i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1 i:/O=Digital Signature Trust Co./CN=DST Root CA X3

尽pipe没有SNI标志（ -servername ... ），但它获得panel.的证书panel. 代替。

因此，目前您的原始报告“ 它在浏览器中运行良好，但我仍然无法使用[其他工具]连接 ”似乎归结为“ 它工作正常，除非我连接使用工具，不应该在这个设置上工作 “。这看起来有点像没有问题。