☰

Verhält sich cURL in Bezug auf SSL-Zertifikate anders, wenn das Flag -v (ausführlich) verwendet wird?

tag-icon • tag-icon ssl ssl-certificate curl
Verhält sich cURL in Bezug auf SSL-Zertifikate anders, wenn das Flag -v (ausführlich) verwendet wird?

Verwendet Ubuntu 16.04, curlVersion 7.47.0

Ich versuche, ein SSL-Zertifikatproblem zu debuggen, und sehe ein merkwürdiges Verhalten bei der Verwendung curl. Wenn ich einfach ausführe:

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'

Wenn ich jedoch die -vFlagge anhänge:

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"}

Beachten Sie, dass ganz am Ende {"message": "Hello World"}die erwartete Antwort steht.

Warum curlverhält es sich im Hinblick auf die Vertrauenswürdigkeit der SSL-Zertifikatdetails anders, wenn es im ausführlichen Modus ausgeführt wird? manSoweit ich das beurteilen kann, ist dies auf der Seite nicht angegeben.

Antwort1

Es scheint, dass Sie zwei verschiedene A(oder AAAAfür IPv6) Datensätze mit demselben Hostnamen haben. Wenn es mehrere Datensätze für einen Hostnamen gibt, führt dies dazu, dass jede Suche nach diesem Hostnamen im Round-Robin-Stil eine andere IP-Adresse zurückgibt.

Wenn Sie Anfragen mit und ohne ausführlichen Modus abwechseln, wechselt auch die IP-Adresse, was dazu führt, dass die nicht ausführlichen Anfragen die falsche IP-Adresse erreichen, während die ausführlichen Anfragen die richtige IP-Adresse erreichen. Aus diesem Grund erscheint das richtige Zertifikat in der ausführlichen Adresse gemäß der

subject: CN=myapp.com

Zeile, während im Fehler für die nicht ausführliche Adresse ein anderes Zertifikat angegeben wird.

Die richtige Lösung hierfür besteht darin, den falschen ADatensatz zu entfernen, sodass nur die Adressen der Webserver angezeigt werden, die für die Bereitstellung Ihrer Inhalte konfiguriert sind.

verwandte Informationen