I have a httpd Server with PHP7.3 on a RHEL 8 machine.
When I try to connect to our companys LDAPS Server I get the above mentioned error message.
The same code works on another machine (Win 2008 Server, PHP5.X, Apache). There I had to create this file "c:\openldap\sysconf\ldap.conf" with this information:
TLS_REQCERT never
TLS_CACERT C:\Server\Apache24\conf\ssl\myCert.crt
The Certificate is the one I got for my Server with my Domain.
I think it has to do with the certificates I have or have not ...
The RHEL Server at the moment only has a self signed cert and no domain which points to it.
I have no clue what the mentioned hostname nor what the name in the peer certificate ist. Not to mention I don´t know the peer certificate.
The web really couldn´t help me in hours of googling where TF I have to put a config file on RHEL for the LDAP functionality
You guys are my last hope :)
THX
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'm using Rackspace API in PHP, and it just stopped working (everything worked fine 3 days ago). It uses guzzle, who uses curl. And curl just stopped working.
[Thu Jun 21 14:55:36 2018] [error] [client xxx.xx.xxx.xx] PHP Fatal error: Uncaught exception 'Guzzle\\Http\\Exception\\CurlException' with message '[curl] 60: [url] https://identity.api.rackspacecloud.com/v2.0/tokens' in
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php:359\nStack trace:\n#0
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(292): Guzzle\\Http\\Curl\\CurlMulti->isCurlException(Object(Guzzle\\Http\\Message\\EntityEnclosingRequest), Object(Guzzle\\Http\\Curl\\CurlHandle), Array)\n#1
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(257): Guzzle\\Http\\Curl\\CurlMulti->processResponse(Object(Guzzle\\Http\\Message\\EntityEnclosingRequest),
Object(Guzzle\\Http\\Curl\\CurlHandle), Array)\n#2
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(240): Guzzle\\Http\\Curl\\CurlMulti->processMessages()\n#3
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(224): Guzzle\\Http\\Curl\\CurlMulti->executeHandles()\n#4
/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(111)
The important part from the error is the following:
[curl] 60: [url] https://identity.api.rackspacecloud.com/v2.0/tokens
I get an error 60 from Curl, who means is an SSL cert error. Most answer say's the solution to this problem is: deactivate ssl or download a new cert.
curl: (60) SSL certificate : unable to get local issuer certificate
https://es.stackoverflow.com/questions/174276/curl-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate-url-h
I won't deactivate SSL, I can't use http instead of https and I want to avoid having to get into the machine and downloading a new cert.
If someday I have an old cert again, my site is going to stop working. What is the correct way to fix this?
This server has CenOs 6, We're using PHP 5.3.3 and curl 7.19.7
---- Edit ----
So, my problem is because of the change in the certificates of curl. From https://curl.haxx.se/docs/caextract.html
This bundle was generated at Wed Jun 20 03:12:06 2018 GMT .
There is a tool on linux called update-ca-certificates who solves this problem, also, the curl site say's you can run
curl --remote-name --time-cond cacert.pem https://curl.haxx.se/ca/cacert.pem
But, I don't know, someday I'll see the system stop working properly, I gonna get into the machine an run this command, and, that's all?, What doest the other people do?, set a cron with this command? or what?
Older versions of Guzzle made use of their own CA file that was bundled with the Guzzle library. It would use that file instead of system's (/etc/pki/tls/certs).
If you can get things working with cURL from the command line but get this error in Guzzle that is likely the culprit.
Things were changed to use the system CA bundle by default in late 2014.
https://github.com/guzzle/guzzle/issues/623
https://github.com/guzzle/guzzle/pull/800
The behaviour of newer (> 3.0 ?) versions is described here (see verify configuration flag):
Check if openssl.cafile is set in your php.ini file.
Check if curl.cainfo is set in your php.ini file.
Check if /etc/pki/tls/certs/ca-bundle.crt exists (Red Hat, CentOS, Fedora; provided by the ca-certificates package)
Check if /etc/ssl/certs/ca-certificates.crt exists (Ubuntu, Debian; provided by the ca-certificates package)
Check if /usr/local/share/certs/ca-root-nss.crt exists (FreeBSD; provided by the ca_root_nss package)
Check if /usr/local/etc/openssl/cert.pem (OS X; provided by homebrew)
Check if C:\windows\system32\curl-ca-bundle.crt exists (Windows)
Check if C:\windows\curl-ca-bundle.crt exists (Windows)
If someday I have an old cert again, my site is going to stop working. Curl should download a new cert by himself? isn't it?.
The concept of TLS is that the server sends its certificate to the client, shows a prove that it actually owns the private key belonging to the certificate and then the client checks if the certificate is considered trusted. Trusted means among others that the certificate was issued by a locally trusted CA (certificate authority).
Typically the client has a set of CA it trusts, i.e. CA like Let's Encrypt. If the certificate was issued by such an already trusted CA no changes to the client are needed whenever the certificate is changed as long as the issuer CA is still trusted and the server is configured properly to provide all intermediate CA certificates which are needed to build the trust path.
If instead you have a self-signed certificate or a certificate signed by some private CA the client has no kind of trust anchor it can use to verify the certificate. In this you need to provide the necessary trust anchor to the client. In case of a private CA it is sufficient to setup the client once with this private CA and it will accept also later certificates issued by this CA. But in case of a self-signed certificate this means that you need to update the expected certificate at the client whenever you update the certificate at the server. There is no automatic way to do it - because how should the client verify that it gets the correct new certificate without having an established trust to the party providing the new certificate?
This issue was caused by the change in the certificates of curl. From https://curl.haxx.se/docs/caextract.html
This bundle was generated at Wed Jun 20 03:12:06 2018 GMT .
There is a tool on linux called update-ca-certificates who solves this problem, also, the curl site say's you can run
curl --remote-name --time-cond cacert.pem https://curl.haxx.se/ca/cacert.pem
Just consider any of these commands may be needed to run again in the future if the certificates are renovated again.
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 have been using EasyPHP 5.3.2i on Windows XP for a few years and I like to test my website offline before uploading it to my web server. This has always been fine until now, when I need to incorporate SSL connections as part of its functionality. My code works fine when running on the web server, but when trying to open an SSL connection from my local computer (127.0.0.1 etc.) I get the following:
SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
It was easy enough to install the certificate on my web server, but placing it in the same directory on my local setup doesn't fix this error. Do I have to install it elsewhere or is there something else preventing my establishing an SSL connection here?
Try setting the cURL option CURLOPT_SSL_VERIFYPEER to false. This will disable verification of the peer's certificate. However, you only want to use this option on your testing server. You can view the full list of options here.