3

I have this error when using CURLOPT_SSL_VERIFYHOST:

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

What I tried:

1 - turning off VERIFYHOST is not an option, I need this to login to https page

2 - downloaded certificate and I use it like this:

    curl_setopt($c, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($c, CURLOPT_SSL_VERIFYHOST, 2);
    curl_setopt($c, CURLOPT_CAINFO, getcwd() . '/certificate.pl.crt');

And I still get the same error.

3 - I turned on ssl_module in Apache extensions (I use WAMP)

4 - I turned on php_openssl in PHP extensions

What else should I do? From phpinfo(); I know that I have:

mod_ssl/2.2.22 
OpenSSL/0.9.8u

And it still doesn't work. What else should I do :( ?

Littm
  • 4,923
  • 4
  • 30
  • 38
Anfo Anfo
  • 31
  • 1
  • 2
  • verifyhost doesn't disable ssl. it simply turns off validation of the server-side certificate. Are you sure that the .crt you've got is the cert of the CA that signed the ssl cert running the site you're attempting to hit? Downloading the site's own .crt is of no use. – Marc B Sep 26 '12 at 05:07
  • @MarcB I downloaded the .crt from https://poczta.interia.pl/ but the POST info goes to https://logowanie.interia.pl - is that a difference? Because the original name of the file was *.interia.pl.crt so I figured it's for the whole website. https://logowanie.interia.pl redirects me to mainpage so it's impossible for me to download the crt from there – Anfo Anfo Sep 26 '12 at 05:09
  • I just turned off VERIFYHOST and I still have the error, I checked and having CURLOPT_SSL_VERIFYPEER on True gives me the error, but with VERIFYPEER off I can't login (it says I need to turn on cookies, but I have cookie.txt with chmods so I think SSL is the problem) – Anfo Anfo Sep 26 '12 at 05:15
  • 1
    *.interia.pl would be a wildcard cert, covering all hostnames on the interia.pl domain. but for the .crt file to be valid in validating the host you're trying to hit, it has to be the public key cert of the certificate authority that signed your site's cert, not the cert itself. – Marc B Sep 26 '12 at 05:15
  • see: http://stackoverflow.com/questions/4660610/if-curlopt-ssl-verifypeer-is-false-is-the-data-transfer-no-longer-secure – Marc B Sep 26 '12 at 05:16
  • +1 For incrementing Your steps from 0 :) – WooCaSh Sep 26 '12 at 05:20
  • I'm getting a similar error from stream_socket_client when trying to connect to https://www.google.com using HTTP_Request2, https://gist.github.com/2983b07f3d8c6d13c19b – Chris Chilvers Sep 26 '12 at 09:22

1 Answers1

0

had to edit this as I missed some comments before.

If you don't try to import your certificate and switch peer validation off, your transport should still be SSL secured if I'm not mistaking, so if the goal is to get it over ssl , then I wouldn't bother messing with the import of certificates. Of course if you do want some more peace of mind it's a different thing.

Glenn Plas
  • 1,608
  • 15
  • 17
  • SSL security has two main goals: 1. encryption for privacy 2. validation to ensure you're communicating with the correct server. Without validation you're missing roughly half of the security model. – Mark Fox Mar 04 '14 at 08:32
  • IF you own the server and it's for internal use, people tend to selfsign. Who do you trust the most, yourself or a third party? Self signed certificates are not less secure. You could easily terminate SSL on a loadbalancer and then sniff the session from there to the internal nodes. Clients have no idea what goes on. SSL doesn't protect you from that. Importing a self signed certificate is not less secure. It just looks bad in the browser. You don't talk to the right server either, you talk to the right service. You'll never know what server takes care of you, you do know the service – Glenn Plas Mar 05 '14 at 13:31
  • That's a good point. Still, for self-signed certs does `CURLOPT_SSL_VERIFYHOST` give you extra assurance you're not dealing with a forgery? TLS is complicated and specifically with cURL the implementation details are a little murky to me. Either way it really depends what data you're trying to protect and what you're use case is. If your cert is issued by a CA I think it's still a good idea to verify the host — see [SSL Man in the Middle Proxy](http://crypto.stanford.edu/ssl-mitm/) which can proxy and forge: however the user gets a warning since the forgery is not issued by a CA – Mark Fox Mar 05 '14 at 23:51
  • Absolutely true. That curl option basically says: don't check the certificate. A couple months back I had to do this after SSL cert on an API got expired on an CA signed cert. TLS is quite the pain to balance too as the SSL session ID changes between TLS tickets. I would not want to implement that. There is a very decent tool out there to help test SSL. See https://github.com/vincentbernat/rfc5077 – Glenn Plas Mar 10 '14 at 10:23