cURL SSL certificate problem, verify that the CA cert is OK.

[gnatbite]

Hi Leute, zunächst ein paar Infos zu meiner Config:

Apache/2.2.3 (Debian)
mod_fastcgi/2.4.2
mod_ssl/2.2.3
OpenSSL/0.9.8c

Installiert habe ich noch:
php5-curl_5.2.0-8+etch4_i386.deb
ZendOptimizer-3.2.8-linux-glibc21-i386

Auf einer Domain habe ich einen Online-Shop laufen (Oxid Shop), der cURL und Zend braucht. Leider habe ich ein Problem mit cURL in Verbindung mit SSL.

Wenn ich mit cURL über SSL eine andere Domain abrufen möchte, bekomme ich folgende Fehlermeldung:

CODEBEISPIEL:

Code: Select all

...
$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,  1);
$url = "https://www.domain.com";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_exec ($ch);
...

FEHLERMELDUNG:

Code: Select all

60 -> SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Dazu muss ich sagen, dass auf dem Server 2 unterschiedlich Zertifikate konfiguriert sind. (natürlich auf 2 verschiedenen IP-Adressen) Bisher hat auch alles funktioniert, nur cURL möchte nicht so wie ich möchte.

Jemand ne Idee woran das liegen könnte?

[Joe User]

man curl:

Code: Select all

--cacert <CA certificate>
		(HTTPS) Tells curl to use the specified certificate file to verify the peer. The file may contain multiple CA certificates. The certificate(s) must be in PEM format.

		curl recognizes the environment variable named 'CURL_CA_BUNDLE' if that is set, and uses the given path as a path to a CA cert bundle. This option overrides that variable.

		The windows version of curl will automatically look for a CA certs file named curl-ca-bundle.crt, either in the same directory as curl.exe, or in the Current Working Directory, or in any folder along your PATH.

		If this option is used several times, the last one will be used.

--capath <CA certificate directory>
		(HTTPS) Tells curl to use the specified certificate directory to verify the peer. The certificates must be in PEM format, and the directory must have been processed using the c_rehash utility supplied with openssl. Using --capath can allow curl to make https connections much more efficiently than using --cacert if the --cacert file contains many CA certificates.

		If this option is used several times, the last one will be used.

[gnatbite]

Danke für Deine Antwort, ich bin jetzt ein wenig weiter.

Folgende Situation. Auf dem Server selbst habe ich immer noch ein Problem.

Wie gesagt, dort sind 2 Zertifikate konfiguriert, die auf unterschiedlichen IP-Adressen laufen.

Zert1 = Domain1.de
Zert2 = http://www.Domain2.com

Wenn ich jetzt von einem EXTERNEN Server mit curl auf eine der Domains zugreife, funktionieren beide Zertifikate einwandfrei.

Zum Beispiel

Code: Select all

curl https://www.domain2.com

Wenn ich jedoch auf der Konsole des Servers bin, auf dem die Domains laufen, bekomme ich jedoch folgende Fehlermeldung:

Konsole:

Code: Select all

curl https://www.domain2.com

Fehlermeldung:

Code: Select all

curl: (51) SSL: certificate subject name 'domain1.de' does not match target host name 'www.domain2.com'

Irgendwie scheinen sich beide Zertifikate in die Quere zu kommen.
Die jeweiligen Dateien liegen unter: /etc/ssl/cersts

Für domain1.de und http://www.domain2.com

Code: Select all

domain1.de.key
domain1.de.crt
domain1.de.pem
...

www.domain2.key
www.domain2.crt
www.domain2.pem

Jemand ne Idee?

[gnatbite]

Habe es gelöst. Es war echt ein dummer Fehler.

Auf dem besagten Server läuft ein lokaler DNS-Server, der für http://www.domain2.com eine falsche IP (aus Vorzeiten) konfiguriert hatte. Aus diesem Grund hat curl auf den falschen VirtualHost zugegriffen und somit das falsche Zertifikat benutzt. :-(

Aaaaaaaaaaaaaaaaaaahhhhhhhhhhhhh

4 Stunden gesucht um den Fehler zu finden. :-/

[flo]

/etc/hosts wäre mein Favorit gewesen - hing aber am Telefon :-(