I am running Bolt CMS locally on my machine using XAMPP. I just upgraded to version 2.0.1 today and everything seems to be working great. The only issue I am having is installing extensions.
On the view/install extensions page, I am seeing this message:
The Bolt extensions Repo at https://extensions.bolt.cm/list.json is currently unavailable. Check your connection and try again shortly.
I do have an active internet connection and am not sure why I cannot connect to the repository from the extensions page. Any help would be appreciated!
Update
In the CommandRunner.php file's setup method, there is this line:
$json = json_decode((file_get_contents($this->packageRepo)));
The problem is coming from the file_get_contents($this->packageRepo) call
The error message being returned from that call is
file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Update 2
The issue is not related to bolt CMS but rather my XAMPP configuration. However, if someone else using bolt CMS locally with XAMPP has already tackled this issue, I would appreciate their input.
At this point, I have not been able to solve the SSL issue with my local server.
I did, however, find a solution that allows me to install bolt extensions.
The solution is to open up the config.yml file and add the following:
extensions:
site: 'http://extensions.bolt.cm/'
This will tell bolt to use the http URL rather than https. I would recommend using the secure URL in production, but this has allowed me to install extensions on my local server until I solve the underlying problem.
I found that the following fixed it correctly for me!
PHP cURL error code 60
From that post:
Use this certificate root certificate bundle:
https://curl.haxx.se/ca/cacert.pem
Copy this certificate bundle on your disk. And use this on php.ini
curl.cainfo = "path_to_cert\cacert.pem"
Related
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).
My PHP Mailgun interface had been working for 2 years until yesterday 1/23/2018 at about 12 noon central time.
Now all calls to the Mailgun API are returning the SSL certificate problem
Exception 0 [curl] 60: SSL certificate problem: unable to get local issuer certificate [url] https://api.mailgun.net/v2/
Curl also returns the same problem at the command line when attempting to access the mailgun API.
We have downloaded and installed the latest cacert.pem file from
https://curl.haxx.se/docs/caextract.html and includeded the path to this file in the php.ini file parameter curl.cainfo = /path/to/cacert.pem and the openssl.cafile = /path/to/cacert.pem
We have restarted our application and rebooted our server but the problem is not fixed.
Is anyone else having the same problem with the PHP Mailgun API ?
Is there a way to disable the SSL certificate check through the Mailgun API ?
The SSL Certificate problem with the PHP Mailgun API was resolved by copying the latest cacert.pem file to the following directory :
..PHP\v5.6\vendor\guzzle\guzzle\src\Guzzle\Http\Resources\
Apparently the PHP MailGun API uses this directory for the certificates when calling the guzzle and curl interfaces.
Changing the PHP.ini file parameter curl.cainfo = "/path/to/cacert.pem" is not sufficient to resolve this problem.
Do we really need to install guzzle to fix this issue? I encounter same issue.
I just came to SO myself to post a resolution my team and I found on this issue as well. As we have a Laravel 4.2 website running Guzzle 4.x for Mailgun mail delivery, all emails ceased functioning as Steve said on 1/23 around Noon.
For us, we simply had to update the cacert.pem found in the /vendor/guzzlehttp directory that the package uses and it came back online.
I can confirm updating php / curl on my dead ass old production server resolved this problem.
Actually, this should be sufficent:
sudo apt-get update && sudo apt-get upgrade
I fixed this problem... you just need to change de "pem" file inside:
guzzle/guzzle/src/Guzzle/Http/Resources/
You need to get de cacert.pem here... the last version:
https://curl.haxx.se/docs/caextract.html
And after, just change in your folder.
Actually, it's not a bug; it's for security reasons. To make it work, change
$sslEnabled = true
to
$sslEnabled = false
You can read extra details at this github issue.
I have a problem with wordpress. When I want to do install of some plugin or update Wordpress to new version then I get error:
Download failed. cURL error 77: Problem with the SSL CA cert
Path? Access rights?
I didn't change anything on my website. I have shared hosting.
I have the same issue with OVH and a let's encrypt certificat. This is commun bug while you have a php version to 5.6. it's seems that is working fine with PHP 7.
Both, curl, file_get_contents and getimagesize running a file from my own server didn't work.
I correct the url and make it as a path on a direct URL.
https://example.com/file.css
Become
/home/example.com/file.css
And it works after.
Of course you will need to adapt your scripts with this to detect internal link that can cause the issue.
I am trying to build a twitter feed to search for relevant hashtags and display them in my mobile app. I found a package at http://mlemos.users.phpclasses.org/package/8109-PHP-Generate-RSS-feeds-from-timelines-and-searches.html that seems to do the job. However, opensll isnt loading. i get Error: it was not possible to open the API call URL: establishing SSL connections requires the OpenSSL extension enabled. Now, i have used open ssl on this machine before, and phpinfo says it is enabled. i have checked my php.ini file to make sure the line is uncommented, as well as check my path variable. No success. Google has turned up nothing helpful. Any ideas? Thanks
Ended up using a twitAPI handler package
Trying to make Soap connection to a https:// WSDL source via PHP/Win32, but keep getting the error:
Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning
: failed to load external entity "https://...
If I try to save the WSDL locally and access it then, the SoapFault->faultstring property has the message "SSL support is not available in this build".
After some Googling, seems like PHP SOAP cannot connect to a HTTPS source. HTTP is OK, though.
Is there a workaround for this? Or is there an alternative SOAP version/module I can install?
HTTPS support for SOAP in PHP5
If you’re seeing error messages about missing https wrappers when trying to use SOAP (”Unable to find the wrapper “https” – did you forget to enable it when you configured PHP?” or “[HTTP] SSL support is not available in this build”), you haven’t installed the SSL libraries to support secure transactions.
Uncomment
extension=php_soap.dll
in your php.ini
Uncomment
extension=php_openssl.dll
in your php.ini
Copy
ssleay32.dll
and
libeay32.dll
to your windows system32 directory
Reboot apache, et voila!
I originally found this answer at: http://webponce.com/rants/2008/04/https-support-for-soap-in-php5-under-windows/
I had the same problem. openSSL, cURL were enabled, initiated a SoapClient with option of location to stored certificated, etc, etc.. tried everything.
Turns out it does work in CLI mode. Thus php_sapi = CLI.
As we almost always run our webservices calls as a cronjob, scheduled task in Windows, this is not really a bad thing. I was really glad to get it working!
Update:
Okay, turns out when PHP is running as an Apache module, it uses the by opensll required libraries libeay32.dll and ssleay32.dll from the Apache install. When using PHP in CLI is uses the libraries from the PHP directory/install. Overwriting the 2 Apache dlls with the dlls from the PHP directory did the trick. It now also runs under Apache.
So your PHP version should match with the working dlls for the specific version. When it still doesn't work in the web interface. Please check that Apache isn't loading these dlls from a Windows System directory, specified earlier in your system defined path, which is picked up by Apache.
I've had success with SSL and SOAP using NuSOAP:
http://nusoap.sourceforge.net/