Ssl

LetsEncrypt:連接中的未知 SSL 協議錯誤

  • May 11, 2016

我有一個帶有 LE 證書的主機,它在瀏覽器中執行良好,但我仍然無法使用curl, openssl, wget, POST(libwww-perl) 進行連接:

捲曲

# 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.

郵政

# 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.

虛擬主機配置:

<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 相關。該區域存在一條 DS 記錄:

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

但 A 記錄chat未簽名:

[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記錄chat.codestronaut.com。這會導致 DNS 查找在某些平台上失敗:

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

在你修復你的 DNS 之前,我認為這一切都不可能可靠地工作。要麼讓您的註冊商停止發布DS該區域的記錄,要麼正確簽署您的區域。我並不是說這是您唯一的問題,但擁有一個正常工作的 DNS 幾乎是其他**一切的先決條件,包括調試。

編輯:您說您已禁用 DNSSEC,但更改尚未傳播(可能需要一天時間,因為舊 DS 記錄上的 TTL 為 86400 秒)。使用 DNSSEC 盲客戶端,我無法重現您報告的問題,但我注意到您在該系統上執行 SNI(即,有幾個 SSL 證書可用,包括chat.codestronaut.companel.codestronaut.com)。

curl -v -3明確不支持 SNI(因為 SNI 是 TLS 的擴展,因此在 SSLv3 中不可用)。 openssl s_client一旦收到有關 SNI 的警告,就可以正常工作:

[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

雖然沒有 SNI 標誌 ( -servername ...),但它會獲得證書panel.

因此,目前您的原始報告“它在瀏覽器中執行良好,但我仍然無法使用$$ other tools $$“似乎歸結為“它工作正常,除非我使用不應該在此設置上工作的工具進行連接”。這看起來有點像一個非問題。

引用自:https://serverfault.com/questions/776060