I am using the latest Janrain openid library example and the discovery process seems to work well with Yahoo, myopenid.com and others...
But I am stuck with Google endpoint (https semicolon //www.google.com/accounts/o8/id). Consumer.php just returns a 406 apache error, before I am redirected to google's page.
All my installation is available here :
http://www.coplango.com/vendor/openid/examples/
Click on consumer to try the consumer example, but discovery.php fails the same way,proving it happens during discovery...
You can also check detect.php to check my installation - The HTTP fetching test fails with a 503 because it tries to reach an address which returns a 503. Rest is fine.
I supposed it was down to php-yadis specifying Accept: application/xrds+xml header but I checked the code and other types are also accepted such text/html and application/xhtml+xml.
Anyone came accross this?
Any clue?
Thank you very much!
Ok,
I have investigated further and it seems to be down to my provider, who returns a 406 error if any string containing the death word "/id" is passed as GET parameter. Took me days to figure out it was not down to openid !!
For info I am using PlanetHoster, if anyone else ever comes accross this. I have sent them a ticket request and waiting for their answer.
running the consumer example at my machine, i get the following error:
Got no response code when fetching https://www.google.com/accounts/o8/id
CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
this means curl fails verifying google's https server certificate. you can workaround this by either providing curl with CA certificates to verify google's certificate via CURLOPT_CAINFO/CURLOPT_CAPATH, or - easier - stop validating the cert via CURLOPT_SSL_VERIFYPEER. the following change in Auth/Yadis/ParanoidHTTPFetcher.php accomplishes latter for me:
--- ParanoidHTTPFetcher.php.orig 2009-04-22 02:31:20.000000000 +0800
+++ ParanoidHTTPFetcher.php 2009-09-30 22:35:24.093750000 +0800
## -127,6 +127,9 ##
Auth_OpenID_USER_AGENT.' '.$curl_user_agent);
curl_setopt($c, CURLOPT_TIMEOUT, $off);
curl_setopt($c, CURLOPT_URL, $url);
+
+ // don't verify server cert
+ curl_setopt($c, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_exec($c);
of course, your curl installation must also support ssl - check your phpinfo(). also, if CURLOPT_SSL_VERIFYPEER is disabled, CURLOPT_SSL_VERIFYHOST may also need to be TRUE or FALSE.
see also http://www.openrest.eu/docs/openid-not-completely-enabled-for-google.php (via the Related Why doesn't Google OpenID provider work with PHP-OpenId on my server?).
SOLUTION:
In the .htaccess file put
SecFilterEngine Off
Related
I have read all the internet and tried almost all solutions, nothing works.
If I run curl http://... site, it works but if i run https://... it doesn't.
I' running centos 7 with php 5.6
Nothing happens also if I try the famous answer with
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
The only thing that can help me getting the site is
curl -4svo/dev/null --ciphers ecdhe_ecdsa_aes_128_sha https://.....
however since i need to send my headers, it is not a solution, i need something compatible with the curl_setopt.
UPDATE ERROR
I get this: curl: (35) Cannot communicate securely with peer: no
common encryption algorithm(s).
i think , this problem is caused by the version of cURL not supporting ECC 256 bit SSL certificates and the ECDSA signature algorithm (which is used by CloudFlare). You can test to see if your version of cURL supports this encryption by running:
curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com
If you get the following, then your cURL is out of date:
curl: (59) Unknown cipher in list: ecdhe_ecdsa_aes_128_sha
This is the magic line!
curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ecdhe_ecdsa_aes_128_sha');
I'm trying out Mandrill. It looks nice. I signed up with an account and got an api key. Downloaded the Mandrill PHP wrapper from
https://bitbucket.org/mailchimp/mandrill-api-php
This post seemed to have a pretty good hello-world Mandrill email example, so I tried it out:
Simple php function to send an email with Mandrill
Kept getting this error:
API call to templates/add failed: Problem with the SSL CA cert (path? access rights?)
I followed the instructions from these S.O. posts:
error in send email using Mandrill (php)
HTTPS and SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, CA is OK
Grabbed the .pem file from http://curl.haxx.se/docs/caextract.html
and made sure the the curl api pointed to that file inside the Mandrill api
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, TRUE);
curl_setopt ($ch, CURLOPT_CAINFO, "pathto/cacert.pem");
The .pem file is readable. No crazy permissions situations.
No help. Same deal:
API call to templates/add failed: Problem with the SSL CA cert (path? access rights?)
Googling around I followed the CentOS 6.0 steps here:
http://kb.kerio.com/product/kerio-connect/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html
As well as the steps here:
http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
Same error. As a last try, I set curl to ignore the ssl-step entirely. This of course is not advised, but I just wanted to feel solid ground under my feet. I went back into Mandrill.php and gave this a shot.
curl_setopt($this->ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($this->ch, CURLOPT_SSL_VERIFYPEER, 0);
Again, same error. I was wondering if someone else can shed some light on this for me. I've exhausted google. (It gave me a recaptcha because I was using it too much). Thanks for your time!
(System: CentOS 6.5, PHP 5.3)
Odd that you're having this issue on Linux (known problem in Windows though).
The only thing I kan think of is that you try to load the the .pem as a default via your php.ini-file, check curl.cainfo and supply an absolute path to the cacert.pem-file. That should make so that you don't have to use CURLOPT_CAINFO – and perhaps gives a better result?
Half off-topic; if you don't need all the features that the API gives you, you can also use an SMTP-connection (always easier to work with).
I'm debugging an issue that someone is having in accessing a payment gateway using a PHP plugin. The only way he has been able to avoid a 404 error after clicking the Checkout button is by setting CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to 0. I know this is bad, but does anyone know why this might be? It seems to be distrusting of the SSL certificate of the payment website...could this just be an issue with his server not trusting certain SSL certificates? The response he is getting from the curl_exec() function is just false when the checks are turned on.
EDIT: So I've seen multiple solutions that say to add something similar to this to my curlopt lines after getting the certificate file:
curl_setopt($ch, CURLOPT_CAINFO, getcwd() . "/CAcerts/certificate.cert");
But what if I'm dealing with a bunch of separate customers that are having this issue? That path won't work for everyone. What can I put instead that will apply to each person?
If I can't put a general line, then where would I tell the person to put their certificate file? This would have to be done by their web hosting service, right?
here is a good answer to your problem:
Security consequences of disabling CURLOPT_SSL_VERIFYHOST (libcurl/openssl)
i suggest to analyze the certificate issued by the payment website..
the url used by the php plugin is exactly the same specified in the common name field of the certificate?
If you are sure the certificate provided it's ok, and trusted, You could set the CURLOPT_CAINFO option to trust this certificate and avoid the error:
curl_setopt($ch, CURLOPT_CAINFO, 'C:\path\to\curl-ca-bundle.crt');
Chech your SSL Certificate here : http://www.digicert.com/help/
I had a similar issue because certificates hadn't been good chained.
All of a sudden, my PHP cURL implementation that access sites over SSL stopped working. After some digging around in the cURL response headers I discovered that the issue was a result of cURL not liking the sites SSL cert, giving the error:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Now I didn't test it with other sites and I know there are solutions to add Mozilla's certs to cURL. But to get stuff to work I simply added a new cURL option to disable SSL validity checks (CURLOPT_SSL_VERIFYHOS).
But I am still confused as to how this would stop working in just one day. It worked yesterday. The cert on the site didn't change and it is still a valid, unexpired, Verisign-issued cert.
Had this happen to me last month as well, and the only reason was that the SSL certificate in question was expired. So I just renewed it and the curl ssl link worked again. If you happen to deal with self-signed certificates it's the same deal btw, you either import it or switch of the verification.
That's the only thing I can think off but you state you already verified that...weird. Any chance to take a peek at the site's certificate or is it private? If you haven't changed anything it's almost certainly that something happened to the SSL certificate.
Try These two options in curl
CURLOPT_SSL_VERIFYPEER, FALSE
CURLOPT_SSL_VERIFYHOST, 2
I should have paid more attention to my classes that covered security. I'm quite confused about something. To start, here's the background of what I'm trying to accomplish.
I have a web service that I need to access. The web service is set up as HTTPS. The traffic between client and server is encrypted (this doesn't have to do with authentication).
I'm interacting with the web service via cURL and PHP. I've gotten an example to work locally over HTTP and I'm fairly confident I'm on the right track with regards to cURL/PHP side of things.
When using the HTTP version of the code to access a web service over HTTPS, I am getting an error code 60 "SSL certificate problem, verify that the CA cert is OK" (error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)
From my reading, it seems that I need a PEM file and I need to set additional cURL options such as the following:
CURLOPT_CAINFO
CURLOPT_SSLCERT
CURLOPT_SSLKEYPASSWD
My question is how do I know where to get the PEM file or whether I can simply make it? This is probably going to be an obvious answer as I'm sure I'm missing something but I figure I just need to ask and get the background I'm missing.
Amendment: The web service is using a certificate signed by VeriSign. So it's not a self signed certificate. Also, the web service is owned and operated by an external organization.
Thanks.
Despite googling around prior to asking this, it seems I've stumbled upon the answer after a bit of back-n-fourth with 'thatidiotguy' (his user name, not my name for him. ;-) ).
cURL, out of the box, does not trust any CA (VeriSign or otherwise). This needs to be setup on your server. To "solve" the problem, you have two options. You can bypass the verification with the following command:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
Note that this is not optimal with regards to security. Any certificate, signed by a CA or not, will be accepted as trusted.
The proper fix involves getting the original certificate (in my case this means the web service) and "exporting" the certificate as a X.509 Certificate (PEM). The certificate then needs to appropriately moved to the server and the following configurations set:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); //Check that the common name exists and that it matches the host name of the server
curl_setopt($ch, CURLOPT_CAINFO, getcwd() . "/path/to/cert/my-exported.crt"); //PEM file
Source: http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
The answer is very simple. You need to download a certificate bundle, one that also ships with regular browsers.
Luckily that work is already done for you here:
http://curl.haxx.se/docs/caextract.html
Once downloaded you specify the path to this file with CURLOPT_CAINFO.