☰

-v (詳細) フラグを使用する場合、cURL は SSL 証明書に関して異なる動作をしますか?

tag-icon • tag-icon ssl ssl-certificate curl
-v (詳細) フラグを使用する場合、cURL は SSL 証明書に関して異なる動作をしますか?

Ubuntu 16.04、curlバージョン 7.47.0を使用

SSL 証明書の問題をデバッグしようとしているのですが、 を使用すると奇妙な動作が見られますcurl。以下を実行すると、

ubuntu@ip-172-30-0-81:~$ curl https://myapp.com/hello
curl: (51) SSL: certificate subject name (cloud.mynameserver.com) does not match target host name 'myapp.com'

ただし、フラグを添付すると-v:

ubuntu@ip-172-30-0-81:~$ curl -v https://myapp.com/hello
*   Trying {IP REDACTED}...
* Connected to myapp.com ({IP REDACTED}) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 692 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*    server certificate verification OK
*    server certificate status verification SKIPPED
*    common name: myapp.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: CN=myapp.com
*    start date: Sat, 31 Dec 2016 22:57:00 GMT
*    expire date: Fri, 31 Mar 2017 22:57:00 GMT
*    issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
*    compression: NULL
* ALPN, server accepted to use http/1.1
> GET /hello HTTP/1.1
> Host: myapp.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.0 (Ubuntu)
< Date: Sat, 21 Jan 2017 00:25:15 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
<
* Connection #0 to host myapp.com left intact
{"message": "Hello World"}

最後の が{"message": "Hello World"}期待される応答であることに注意してください。

curl詳細モードで実行しているときに、SSL 証明書の詳細の信頼に関して動作が異なるのはなぜですか?man私の知る限り、これはページには明記されていません。

答え1

同じホスト名を持つ 2 つの異なるA(またはIPv6 の) レコードがあるようです。ホスト名に複数のレコードがある場合、そのホスト名の各検索でラウンドロビン スタイルで異なる IP アドレスが返されます。AAAA

詳細モードありとなしでリクエストを交互に送信すると、IPアドレスも交互に送信され、詳細モードなしのリクエストは間違ったIPアドレスにヒットし、詳細モードのリクエストは正しいIPアドレスにヒットします。これが、正しい証明書が詳細モードのアドレスに表示される理由です。

subject: CN=myapp.com

行には証明書が表示され、非詳細アドレスのエラーには別の証明書が表示されます。

この問題を正しく修正するには、誤ったAレコードを削除して、コンテンツを提供するように構成された Web サーバーのアドレスのみが表示されるようにします。

関連情報