curl + https

easteregg

easteregg

0
Hi

ich hab nen debian squeeze LTS

Code: 
# dpkg -l curl openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                           Version                                                        Description
+++-==============================================================-==============================================================-============================================================================================================================================
ii  curl                                                           7.21.0-2.1+squeeze12                                           Get a file from an HTTP, HTTPS or FTP server
ii  openssl                                                        0.9.8o-4squeeze20                                              Secure Socket Layer (SSL) binary and related cryptographic tools

innerhalb von nem php webshop wird jetzt via curl auf ne kreditkarten engine zugegriffen. die haben vor kurzem erst ihre certificate auf einen aktuelleren stand gebracht.

seit dem sagt mir curl, dass das certificat nicht aktzeptiert wird:

Code: 
# curl https://secure.payengine.de/ncol/prod/orderstandard.asp
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

auf nem debian wheezy funktioniert das alles ohne probleme.

ich dachte erste, die entsprechende certificate sind bei ca-certertificates ( version 7.21.0-2.1+squeeze12 ) nicht mit dabei und hab sie deswegen händisch nachgereicht und via

Code: 
# update-ca-certificates

nachgereicht. allerdings aktzeptiert weiterhin weder curl noch wget das zertifikat.
ich bin etwas ratlos, funktioniert das einfach mit der openssl version nicht?

es geht um das hier: https://www.ssllabs.com/ssltest/analyze.html?d=secure.payengine.de&latest
 
Gib die Chain oder das CA Zertifikat direkt an, anstatt einen ungeschützten Ordner zu verwenden, aus dem Zertifikate gelöscht oder in dem Zertifikate hinzugefügt werden können:
Get a CA certificate that can verify the remote server and use the proper option to point out this CA cert for verification when connecting. For libcurl hackers: curl_easy_setopt(curl, CURLOPT_CAPATH, capath);

With the curl command line tool: --cacert [file]
Zum Vergrößern anklicken....
Siehe cURL - Details on Server SSL Certificates.

Das CA Zertifikat kannst du z.B. mittels openssl herunterladen: openssl s_client -showcerts -connect host.tld:443.
 
daran hab ich auch schonmal gedacht und hab mir das file via

Code: 
openssl s_client -showcerts -connect secure.payengine.de:443 </dev/null 2>/dev/null|openssl x509 -outform PEM > payengine.pem

runtergeladen und dann mit an curl übergeben.

Code: 
curl --cacert payengine.pem https://secure.payengine.de

was aber nicht aktzeptiert wird.

Code: 
# curl --cacert payengine.pem https://secure.payengine.de
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
 
Mein Fehler. Die Chain ist unvollständig und liefert das Zertifikat der RootCA nicht mit aus. Das Zertifikat findest du hier (Root 10):

Code: 
$ curl --verbose --cacert VeriSign-Universal-Root-Certification-Authority.pem https://secure.payengine.de 1>/dev/null
* About to connect() to secure.payengine.de port 443 (#0)
*   Trying 84.199.92.188...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* connected
* Connected to secure.payengine.de (84.199.92.188) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: VeriSign-Universal-Root-Certification-Authority.pem
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* 	 subject: C=DE; ST=Hessen; L=Eschborn; O=ConCardis GmbH; OU=IT; CN=secure.payengine.de
* 	 start date: 2015-04-29 00:00:00 GMT
* 	 expire date: 2017-05-29 23:59:59 GMT
* 	 subjectAltName: secure.payengine.de matched
* 	 issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server SHA256 SSL CA
* 	 SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: secure.payengine.de
> Accept: */*
> 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Mon, 01 Jun 2015 15:58:04 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Content-Length: 1281
< Content-Type: text/html
< Cache-control: private
< 
{ [data not shown]
100  1281  100  1281    0     0   7602      0 --:--:-- --:--:-- --:--:-- 10330
* Connection #0 to host secure.payengine.de left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
} [data not shown]

Ohne --cacert:

Code: 
$ curl --verbose https://secure.payengine.de 1>/dev/null
* About to connect() to secure.payengine.de port 443 (#0)
*   Trying 84.199.92.188...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* connected
* Connected to secure.payengine.de (84.199.92.188) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS alert, Server hello (2):
} [data not shown]
* SSL certificate problem: unable to get local issuer certificate
* Closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Zum Nachprüfen:
Code: 
$ openssl s_client -showcerts -connect secure.payengine.de:443 |grep -A 1 "s\:"
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server SHA256 SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
 0 s:/C=DE/ST=Hessen/L=Eschborn/O=ConCardis GmbH/OU=IT/CN=secure.payengine.de
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server SHA256 SSL CA
--
 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server SHA256 SSL CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority
^C

Hier fehlt also das Zertifikat für VeriSign, Inc. Ein Blick in das letzte Zertifikat liefert den Identifier dafür:
Code: 
$ openssl x509 -text -in symantec.pem
[...]
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority
[...]
        Subject: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 Secure Server SHA256 SSL CA
[...]
            X509v3 Authority Key Identifier: 
                keyid:B6:77:FA:69:48:47:9F:53:12:D5:C2:EA:07:32:76:07:D1:97:07:19
[...]

Bei Verisign gibt es unter diesem Namen (CN=VeriSign Universal Root Certification Authority) nur ein (selbst-signiertes) Zertifikat, welches auch den genannten Identifier besitzt:

Code: 
$ openssl x509 -text -in VeriSign-Universal-Root-Certification-Authority.pem 
[...]
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority
[...]
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority
[...]
            X509v3 Subject Key Identifier: 
                B6:77:FA:69:48:47:9F:53:12:D5:C2:EA:07:32:76:07:D1:97:07:19
[...]

Die Überprüfung der Signatur des Symantec-Zertifikat lässt sich ebenfalls erfolgreich testen:
Code: 
$ openssl verify -CAfile VeriSign-Universal-Root-Certification-Authority.pem symantec.pem 
symantec.pem: OK
 
Zuletzt bearbeitet:
wow vielen dank!
das ist/war der ganze fehler :) und dabei wieder was neues gelernt und mir ne menge aufwand erspaart!
 
eine frage noch.

war es meine aufgabe sicherzustellen, dass squeeze das certificate nicht hat, oder müsste der anbieter das in seiner certificate chain bereitstellen?
 
Da gibt es durchaus unterschiedliche Auffassungen. Sowohl BSI, als auch Qualys oder OWASP empfehlen in ihren Best Practices die Rückgabe der "vollständigen" Chain - was auch immer vollständig in diesem Zusammenhang bedeutet. RFC5246 gibt an, dass ein Client auf beide Szenerien (Chain mit und ohne RootCA-Zertifikat) vorbereitet sein sollte:
RFC5246 hat gesagt.:
Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
Zum Vergrößern anklicken....
Symantec beschreibt dagegen in ihren Anleitungen ausschliesslich die Auslieferung der Zwischenzertifikate, aber nicht die des RootCA Zertifikats.

Setzt man auf vollständig auf Maßnahmen wie DANE zur Zertifikatsvalidierung, so ist die Auslieferung des RootCA Zertifikats sinnvoll, dann hier muss davon ausgegangen werden, das das RootCA Zertifikat nicht bekannt ist. Bei Browsern wird dagegen davon ausgegangen, dass es bekannt ist, denn es muss ja im Trusted Root Store vorhanden sind, damit ihm überhaupt vertraut wird. Ob es mitgeliefert wird oder nicht ist damit eher zweitrangig. Sprich, es kommt ein bisschen drauf an, ob dem Anbieter der Schnittstelle bekannt ist, wie der Client die Zertifikatsvalidierung durchführt (DANE, Trusted Root Stores, Notaries, ...).
 
dann hätte es tendentiell eher bei dem problem auf dem system vorhanden sein sollen, wobei das vermutlich nicht der fall war, weil das squeeze eben so alt ist.
 
Code: 
$ openssl x509 -text -in symantec.pem 
[...]
        Validity
            Not Before: Apr  9 00:00:00 2013 GMT
            Not After : Apr  8 23:59:59 2023 GMT
[...]

Squeeze ist am 06.02.2012 veröffentlich worden, Wheezy am 04.05.2013. Es ist also sehr wahrscheinlich, dass das Zertifikat nicht in Squeeze enthalten ist, sondern erst ab Wheezy. Aufgrund der Wichtigkeit würde ich das Zertifikat aber wie gesagt eher in der Applikation hinterlegen und nicht den Root Store des Systems nutzen. Dann würdest du auch nicht mehr auf solche Probleme stoßen, sondern müsstest nur bei einem Zertifikatswechsel (alle 10 Jahre oder bei einem Breach) Hand anlegen. Auch wärst du nicht von politischen Entscheidungen der OS-Distributoren abhängig.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben