facebook API problem with IIS7 - php

I'm having problems with the facebook example code.
Fatal error: Uncaught CurlException: 60: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed thrown in C:\inetpub\wwwroot\src\facebook.php on line 616
I found a solution that I don't know what to do with here. I'm running IIS7 and trying to test this on localhost. The solution specified that I should add
$opts[CURLOPT_CAINFO] = [PATH]/apache/conf/ssl.crt/ca-bundle.crt"; //Or your path to "ca-bundle.crt"
to the code. I found the array where this info should go but I have absolutely no idea where the certificates are stored. I searched my machine for my self-signed cert ("myown") but couldn't find it. I googled for the location of cert files on IIS7 but realized I'd be better of here since maybe I don't even need to specify SSL certs.
Any suggestions? What I want to do is just to be able to run the code, I don't have any requirements of SSL right now.

i think that the certificate is being returned but can not be validated, within C# you can usually do something like so:
ServicePointManager.ServerCertificateValidationCallback = delegate{
return true;
};
so this is a callback that's executed before the certificate is validate and acts as a user validation method.
WARNING: this will validate all certificates regardless
never used IIS but im sure it would be something along these lines.

Related

SSL Verify Server Certificate error when calling API on same localhost (tls_process_server_certificate:certificate verify failed)

My dilemma is that I have two domains running on localhost, domain_a and domain_b. They're both running nginx, apache, and php-fpm. domain_a is running CodeIgniter 3.0.0, and domain_b is running CodeIgniter 4. In another VM, I had domain_a in a Docker container, and was able to hit the API endpoints in domain_b without any issues. Development work made it a requirement to have them both be on the same server, as it's close to how it will be in other environments.
For specifics, we're using the PHP oAuth module, and it throws an error that "making the request failed (dunno why)", which is extremely helpful. After some digging, I found that I could hit other endpoints without issue (such as google.com and a known endpoint outside these domains). I attempted to use cURL in place of oAuth (just a simple test to hit the endpoint), and I consistently get the same error.
tls_process_server_certificate:certificate verify failed
The certs I use are all self-signed for both domains, and I'm able to reach both domains from within the browser without issue. If it matters, both domains have user certs when logging in, but the users aren't the same, as each domain has their own self-signed CA.
My current code is this:
$conn = new OAuth($consumer_key, $consumer_secret, $oauth_sig_method);
$conn->enableDebug();
/*
if (is_on_local()) {
$conn->setCAPath('path/to/cert.cert');
}*/
$conn->disableSSLChecks();
$token = $conn->getRequestToken($auth_url);
I left the commented out part in to show what I've tried - I've tried pointing that to the system cert, domain_a CA, and domain_b CA, none of which worked. It looks like (for some reason) $conn->disableSSLChecks() isn't working, but I'm not sure of that. The error thrown is in the call to getRequestToken().
My etc/hosts file:
127.0.0.1 domain_a.tld
127.0.0.1 domain_b.tld
The actual TLD isn't tld, but again, they work in the browser and it worked before when domain_a was in Docker.
I've already tweaked domain_a enough so CI 3 works with PHP 8, so I'm convinced the problem is talking from one domain to the other. I'm running RHEL 8, and I've already got SELinux set to Permissive (actually disabled, I think, for development). There's nothing in httpd, nginx, php-fpm, or firewall logs. The only indicator I have is what I get from CI 3 logs in domain_a:
Severity: Warning --> OAuth::getRequestToken(): SSL operation failed with code 1.
OpenSSL Error messages:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in /path/to/file
Severity: Warning --> OAuth::getRequestToken(): Failed to enable crypto in /path/to/file
Severity: Warning --> OAuth::getRequestToken(domain_b/oauth/access): Failed to open stream: operation failed in /path/to/file
I feel like the answer is right there, I'm just not seeing it.
As usual, shortly after explaining my issue I found the fix.
Currently, I have the endpoint as https://domain_b.tld/oauth/access. After some tinkering, I got a different error about SSL version. That put me on the track to the correct answer:
http://domain_b.tld:port/oauth/access. I'm able to hit the endpoint now without issue. I've got a virtual hosts file that, even though both domains are on the same port, I had to specify it or the call fails.
If anyone else runs into this issue, check the base URL. I never would have thought about hitting http rather than https as a solution.

Woocommerce Webshop on bitnami stack (ec2): SSL operation failed with code 1. OpenSSL Error messages: error:14090086

I simply can't find a solution to this. I migrated a Wordpress site with a woocommerce shop and payment gateway "Payunity" to a new EC2 machine with a bitnami wordpress stack.
I generated a Let's Encrypt SSL certificate and the entire site works as expected.
Only problem I have is that for some reason on the woocommerce checkout page I suddenly get this error message:
SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate
verify failed
I googled extensively and tried figuring this out but no chance.
Any idea what I have to set on the server to have this go away? I tried modifying the php.ini with the capath and cafile like some threads pointed out but no luck.
Any ideas?
Update: I now moved to Cloudflare as DNS Manager and have the "Full (strict) setting so that the Cloudflare SSL is the one in use. However still the same error, so I figure this has nothing todo with the original Let's Encrypt or now Cloudflare SSL Certificate.
I believe this error message is caused by CURL. According to the CURL FAQ (https://github.com/curl/curl/blob/master/docs/FAQ) section 4.12 (where exactly this error message is mentioned), "it means that curl couldn't verify that the server's certificate was good. Curl verifies the certificate using the CA cert bundle that comes with the curl installation." (vsince CURL 7.10).
As your CURL version is quite old (released on Oct 7, 2015), I would assume that one of the CA/root certificates it is using is too old. I would recommend updating CURL separately (e.g. using this guide: http://pavelpolyakov.com/2014/11/17/updating-php-curl-on-ubuntu/, depending on your OS).
Furthermore, you can check the openssl.cafile option in php.ini that should point to an absolute path containing a more or less recent CA bundle (e.g. "C:\xampp7.3\apache\bin\curl-ca-bundle.crt" for my XAMPP installation). You can try to extract the bundle from the XAMPP .zip (https://www.apachefriends.org/download.html) and replace the path in your php.ini and then restart the server.
In addition, you can check your php.ini if extension=php_openssl.* (extension e.g. dll for Windows) is uncommented, i.e. activated.
Maybe (and this is why I asked what should be shown normally at this place) a script inside the Payunity plugin is trying to fetch something from an URL with a broken certificate or something similar.
EDIT: As pointed out by Sebastian B., you can check the error.log (in case of Apache) for failed file_get_contents() (or similar) calls because the actual URL of the "file" the site PHP tried to fetch is mentioned there.
EDIT: CURL Perl script to create a fresh ca-bundle.crt file based on Mozilla's chain: https://github.com/curl/curl/blob/master/lib/mk-ca-bundle.pl You can try this (or extract one from a fresh CURL installation) and set this as a path in php.ini. Or you can use this from the Nextcloud project (https://github.com/nextcloud/server/blob/master/resources/config/ca-bundle.crt) or another one (just for testing purposes, of course).

SSL Certificate unable to get local issuer certificate php background script

How to solve certificate problem on php background script? The script works if I load it directly in the browser but it isn't working when calling it from system like so:
system ("php somescript.php");
It returned fatal error in console:
Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: unable to get local issuer certificate
What am I missing here?
This is a rather unhelpfully-worded error that the Openssl library logs when it can't or doesn't know how to access the CA certificates on the system, or when it encounters a server/client whose certificate is not signed by a CA it trusts.
Openssl is typically compiled with default CA directory and/or path with the options --configure-ca-path and --configure-ca-bundle.
Check that this is the case for your installation (it most likely is) and that the CA directories do exist and can be read from by your script.
If your script provides its own CA bundle as a replacement for the default ones, also check that the path is correct.
Finally, everything may be set up correctly, in which case the remote certificate's CA isn't trusted by Openssl (since it's not in the list of trusted CAs). In this case you simply have to handle the exception or fix the trust issue, either locally by adding the remote's CA to the bundle or remotely by changing the certificate to one that's trusted.

how to solve curl error 60:ssl certificate problenm in youtube data api V3?

I am learning to work with youtube data api v3 (using PHP). So I downloaded sample api code and some how i manage to download and install composer in my working directory(version 1.4.x) successfully.
Ater this i run the serach.php script it shows following error
Fatal error: Uncaught exception 'GuzzleHttp\Exception\RequestException' with message 'cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)' in C:\wamp\www\youtube feeds\vendor\guzzlehttp\guzzle\src\Handler\CurlFactory.php on line 187
( ! ) GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) in C:\wamp\www\youtube feeds\vendor\guzzlehttp\guzzle\src\Handler\CurlFactory.php on line 187 .
I am using wamp with php 5.5.12 and apache 2.4.9. Also I enabled curl extension from tray and in php.ini file.
If just starting out, do not try to jump into the deep end.
Start with the "restfull" api side of things.
As an example, you can do this.
$url_link = 'https://www.googleapis.com/youtube/v3/videos?part=snippet&id=[VIDEO_ID]&key=[API_KEY]';
$video = file_get_contents($url_link);
$data= json_decode($video, true);
Then you can grab the required info in that call as you like. Like this
$vid = $data['id'];
LIB's are good for streamlining large programs and code, but not always needed.
The issue is due to a missing "cacert.pem" file (or provided by the host operating system that runs php). This file verifies certificate authorities, so that curl can connect to youtube securely (and know it's youtube, and not a victim of a man in the middle attack).
You cna download these files manually, and specify them in your php ini, but the better option is to use the "certainty" php package to manage these. I would advise using composer, it's very easy to start using.

file_get_contents to https server suddenly started failing

I have a number of sites running on caddy. I call between them on the same machine from php apps
file_get_contents('https://myapi.example.com/my/api/call');
up until today it was all working lovely then I started getting
SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
All my certs are from LetsEncrypt.org which have been fetched by Caddy, and since they were working up until very recently I am wondering what has changed.
I have tried setting
verify_peer = false
in various contexts with no success and also I know this kindof breaks SSL which is not a good long term solution.
Any Ideas?
Fundamentally I don't know what caused this error, but revoking my cert and getting a new one solved the problem.
Simply call Caddy with
caddy -revoke myapi.example.com
then restart caddy and the problem was solved.

Categories