Short form: I've got some PHP code that is uploading videos from my site to YouTube. I'm using the usual Google-provided PHP library, google-api-php-client. I have this code running on two servers; it works on one (https://www.example.com) but has suddenly stopped working on the other (https://dev.example.com), after a period of working nicely.
Details: The code doing the transfer is relatively standard, as far as I can tell: Once the libraries are loaded and some variables get some values, I'm doing:
$client = new Google_Client();
$client->setClientId($youtube_client_id);
$client->setClientSecret($youtube_client_secret);
$redirect = filter_var('https://example.com/upload-to-youtube', FILTER_SANITIZE_URL);
$client->setRedirectUri($redirect);
$youtube = new Google_YoutubeService($client);
$client->authenticate();
header('Location: ' . $redirect);
For the server that's not working, the $client->authenticate line throws the error:
Google_IOException: HTTP Error: (0) Problem with the SSL CA cert (path? access rights?) in Google_CurlIO->makeRequest() (line 128 of /var/www/html/example/includes/google-api-php-client/src/io/Google_CurlIO.php).
Other possibly-relevant details:
Back in the Developer's Console for my YT application, I have the following Redirect URIs set up:
https://dev.example.com/delete-from-youtube
https://dev.example.com/upload-to-youtube
https://www.example.com/delete-from-youtube
https://www.example.com/upload-to-youtube
According to the SSL certificate tester I found at https://www.sslshopper.com/ssl-checker.html, the certificates on both sites are visible and valid.
The certificate for dev.example.com is from Comodo; the certificate for www.example.com is from GeoTrust. I suppose I could try getting a new cert from GeoTrust, but I'd rather not spend the money unless I know it will fix the problem.
Both servers are running the same version of curl, if that's relevant.
It seems (to me) that the certificate and access to it should be OK (unless the certificate tester is wrong), so I don't understand where the complaint is coming from. The code and the server configuration has been unchanged for quite a while, hence my search for an external explanation. (I understand that these are Famous Last Words, but whatever.) Any thoughts out there? Thanks!
Potential duplicate question:
Amazon MarketplaceWebServiceOrders requests suddenly failing, PHP curl giving SSL CA cert error?
I had to restart the server, not just apache in order to solve the issue.
Related
We're using the Docusign RestAPI (PHP SDK) from our app and it works great. Authentication mode is JWT. I want to use all the code I've written on a different subdomain, but I get this error:
API call to https://account.docusign.com/oauth/token failed: SSL certificate problem: unable to get local issuer certificate
Both domains, my-domain.com and new.my-domain.com have SSL certs installed. What do I do now? What have I missed?
The DocuSign public certificates page lists all certificates.
Scroll down and look for this:
Install the certificate on your server where you are running the code from.
Do you have the standard set of trusted root certs installed in PHP?
This article may help you.
SOLVED: the new subdomain was operating on a different version of PHP. I added the cert paths to that php.ini file and it works as it should now.
I am getting error like below on DocuSign rest, it was working fine before:
Fatal error: Uncaught DocuSign\eSign\Client\ApiException: Error while requesting server, received a non successful HTTP code [400] with response Body: O:8:"stdClass":2:{s:9:"errorCode";s:35:"HTTPS_REQUIRED_FOR_CONNECT_LISTENER";s:7:"message";s:50:"HTTPS required for Connect listener communication.";}
TIA
This change is discussed in the Jan release notes.
Connect can only be used with https listeners (customers' servers). This applies to both developer and production accounts.
And note that the server must use a certificate that chains to a root cert in the Microsoft standard root cert list. (Self-signed certs won't work.) You can use a free cert from LetsEncrypt or a $15 cert from a reputable CA.
I'm sorry that this update caught you by surprise.
There seems some weird behaviour around this since the recent update.
Please try adding :443 to the URL, this resolved the issue in testing.
I implemented the Xero-API using this library, having implemented it, it worked fine on localhost, then i uploaded to my server then i get this error
Curl error: Problem with the SSL CA cert (path? access rights?)
Assuming that the certs do exist in the path and php has the ability to access the server. Try restart apache first, it might be something simple, if not try regenerate the cert, it might have gotten corrupt somehow.
i'm using mandrill and setting up webhooks is failing. i moved my domain to a new server and set up ssl again.
now when i look at the web hooks admin page i see this error:
- Error: POST to https://my.website.com/hooks/mandrill.php failed: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
when i try to change the url for this webhook, all i get is
- We can't verify that the URL exists. More info
when i contacted mandrill support they suggested that it may be missing intermediate CA for my SSL cert. That browsers wouldn't care but the server did care and would fail.
this url helped me figure out that indeed my intermediate CA was not installed
- https://www.sslshopper.com/ssl-checker.html
ends up i didn't have the intermediate CA enabled in /etc/httpd/conf.d/ssl.conf. the lines were commented out. i removed the comments and restarted apache and all is working well now.
i could save the changed webhook and when i clicked send test it sent them. however there still was a stale error on the webhook about the ssl issue. but it was no longer preventing me from editting or sending webhooks
hope this saves someone else some time
I've developed a small Dropbox based app. I've done all the coding in PHP using symfony 1.4 and the dropbox-php library. Locally on my machine everything works just fine. But on a public test server the the dropbox-php library fails to retrieve the request tokens.
The app key and app secret are the same on both machines and I'm using the PHP OAuth extension as the OAuth library. The Dropbox App is in development mode and I've also enabled additional users for it from the Dropbox App Dashboard.
Not sure if this helps but here's the piece of code:
$oauth = new Dropbox_OAuth_PHP(sfConfig::get('app_dropbox_app_key'), sfConfig::get('app_dropbox_app_secret'));
$tokens = $oauth->getRequestToken();
...and this the exception thrown:
500 | Internal Server Error | Dropbox_Exception_RequestToken
We were unable to fetch request tokens. This likely means that your consumer key and/or secret are incorrect.
From the error message it looks like the the app key and app secret combination is wrong. But the combination is right since it works on my machine and I've been using it for days to develop this small app. The 43 port is open on the server and the php_oauth.dll is loading correctly.
Any ideas about what I'm doing wrong here?
I've switched to Dropbox_OAuth_Curl but it didn't work either. The error:
Curl error: (77) error setting certificate verify locations:
CAfile: rootca
CApath: none
So I've set:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
And it works.
Can this be somehow related to Dropbox_OAuth_PHP not working?