web-dev-qa-db-ja.com

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.

Vhost Config：

<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>
sslapache-2.4opensslcurllets-encrypt
3
Serhii Matrunchyk

あなたの問題はDNSSECに関連していると思います。ゾーンのDSレコードが存在します。

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

ただし、chatのAレコードは符号なしです。

[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

chat.codestronaut.comのRRSIGレコードがないことに注意してください。これにより、特定のプラットフォームでDNSルックアップが単に失敗します。

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

DNSを修正するまで、これらすべてが確実に機能する可能性はあまりないと思います。レジストラにゾーンのDSレコードの公開を停止させるか、ゾーンに適切に署名してください。これがonlyの問題だと言っているわけではありませんが、DNSが機能していることは、everything elseのほとんどの前提条件であり、デバッグも含まれます。

編集：DNSSECを無効にしたとのことですが、変更はまだ反映されていません（古いTTLレコードのDSがだったため、最大1日かかる場合があります） 86400s）。 DNSSECブラインドクライアントを使用して、報告された問題を再現することはできませんが、そのシステムでSNIを実行していることに注意してください（つまり、chat.codestronaut.comとpanel.codestronaut.comの両方を含むいくつかのSSL証明書が利用可能です）。

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.の証明書を取得します。

したがって、現時点では、元のレポート "ブラウザでは正常に機能しますが、[他のツール]を使用して接続できません"は、要約すると "正常に動作しますが、この設定で動作するはずのないツールを使用して接続した場合 "。これは問題ではないように見えます。

10
MadHatter