When executing an openstack command, it is failing to verify a certificate that was signed by an internal CA.
CentOS 7
Root CA installed in /etc/pki/ca-trust/source/anchors
openstack 3.3.0
$ openstack server list
Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. SSL exception connecting to https://XXXXX :13000/v2.0/tokens: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:765)
I hit the url from a browser and downloaded the certificate. Then ran openssl verify successfully.
$ openssl verify -CAfile /etc/ssl/certs/ca-bundle.trust.crt 10.92.50.11.crt
10.92.50.11.crt: OK
Does the root CA need to be placed in another area for the command line to pick it up?
Explicitly pointing at the CA certificate by setting OS_CACERT did the trick. Other people in my environment didn't have to do this. I'm not sure why it was necessary, but that's what fixed my issue.
export OS_CACERT=/path/to/ca.crt
Reference: http://docs.openstack.org/user-guide/common/cli-set-environment-variables-using-openstack-rc.html
Related
I can connect fine with Python to any external https site without this error:
SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108)')))
But I have a local webserver on my laptop with a self-signed certificate that works fine in itself but Python generates an _ssl.c:1108 error when I try to connect to it.
Any ideas?
The python client does not have access and trust the CA certificate that signed the web server certificate. In your case that is the self-signed web server certificate.
To get the python client working, you can do the following:
disable certificate verification. That is not a good idea but I guess is ok for a quick test. The emphasis is on "it is not recommended".
Download the self-signed certificate and make it accessible to the python client and specify it as trusted CA certificate.
Download and install a certificate from well known CAs such as LetsEncrypt (free) or commercial CAs. This is the recommended approach.
You could go into depth on the items mentioned herein and get a conceptual understanding how TLS operates.
EDIT 1: You could also get a free certificate from LetsEncrypt CA. Or you could get a free test certificate from most of the commercial CAs like DigiCert etc. See this link for getting and installing a free test certificate signed by a DigiCert test CA.
See this for details on python client configuration for TLS.
So we have a self-hosted version of Atlassian BitBucket running on Ubuntu server which holds the code repository. We use a SSL certificate from DigiCert . Every year we renew the certificate which has never caused issues. However this time most of the developers are getting the following error when pushing and pulling code from GIT after the certificate was renewed
fatal: unable to access : SSL certificate problem: unable to get local
issuer certificate
Another Error:
fatal: unable to access : Peer's Certificate issuer is not
recognized.
However, when we try to access the website using Chrome (or any other browser), it works fine and there is no error
All searches online point to this error when you're using a self-signed or internal PKI certificate. We are totally stumped on why a certificate issued by a public authority like DigiCert is getting this error.
Any help on this would be highly appreciated.
Ensure the root cert is added to git.exe's certificate store as discussed here.
Tell Git where to find the CA bundle by running:
git config --system http.sslCAPath /absolute/path/to/git/certificates
or copying the CA bundle to the /bin directory and adding the following to the gitconfig file:
sslCAinfo = /bin/curl-ca-bundle.crt
Reinstalling Git.
Ensuring that the complete CA is present, including the root cert.
Check www.atlassian.com more ssl errors for resolutions.
I am getting the below build error :
[ERROR] The svn blame command [svn blame --xml --non-interactive -x -w xxxxx.java] failed: svn: E230001: Unable to connect to a repository at URL 'xxx-xxxx.java'
svn: E230001: Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted
I am using Subversion Edge by Collabnet with jenkins to run the build. Could you please help me out?
Here is the wording of the error message:
svn: E230001: Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted
The error you are getting "Server SSL certificate verification failed: issuer is not trusted" means that there is a problem with the certificate installed on SVN Edge server. The client does not trust the certificate and displays the error. Therefore, you should look into the certificate-related problems on CollabNet Subversion Edge server.
The only possible way to ignore the error is to use --trust-server-cert command line option. You also have to add --non-interactive option because your CI machine runs the Subversion client non-interactively.
If you use Subversion 1.9 client, you can also use --trust-server-cert-failures option which is intended to ignore a wider range of invalid certificates than --trust-server-cert that can only ignore certificates issued by unknown or not trusted certificate authority.
I have an issue installing mongodb via homebrew (new MacBook Pro, OS X 10.10.2, fresh installation). Apperantly, every other package that I try to install (for example wget) is throwing this errors, but the packages are correctly installed. Unfortunately, the installation of brew install mongodb fails with the following error:
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/mongodb-2.6.7.yosemite.bottle.tar.gz
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Error: Failed to download resource "mongodb"
Download failed: https://downloads.sf.net/project/machomebrew/Bottles/mongodb-2.6.7.yosemite.bottle.tar.gz
Warning: Bottle installation failed: building from source.
==> Installing mongodb dependency: scons
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/scons-2.3.4.yosemite.bottle.1.tar.gz
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Error: Failed to download resource "scons"
Download failed: https://downloads.sf.net/project/machomebrew/Bottles/scons-2.3.4.yosemite.bottle.1.tar.gz
Warning: Bottle installation failed: building from source.
==> Downloading https://downloads.sourceforge.net/scons/scons-2.3.4.tar.gz
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Error: Failed to download resource "scons"
Download failed: https://downloads.sourceforge.net/scons/scons-2.3.4.tar.gz
I also found this thread How to fix curl: (60) SSL certificate: Invalid certificate chain, where I added the certificate for downloads.sf.net and downloads.sourceforge.net (both use *.cloudfront.net as its certificate, and therefore, you get a domain missmatch) via Safari to "Always trust". After this, the installation fails with a SHA1 missmatch (and I also ran brew cleanup -s to cleanup the old cached packages):
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/mongodb-2.6.7.yosemite.bottle.tar.gz
######################################################################## 100.0%
Error: SHA1 mismatch
Expected: 4b1749b645a744b38b4959daac46bf80353e3b32
Actual: a2fd3379ea944f6b2f97fb0f79b7b85cb3e14d0b
Archive: /Library/Caches/Homebrew/mongodb-2.6.7.yosemite.bottle.tar.gz
To retry an incomplete download, remove the file above.
Warning: Bottle installation failed: building from source.
==> Installing mongodb dependency: scons
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/scons-2.3.4.yosemite.bottle.1.tar.gz
######################################################################## 100.0%
Error: SHA1 mismatch
Expected: 819d08b7e8c1ba2451db6d7d848f689b108b40aa
Actual: a2fd3379ea944f6b2f97fb0f79b7b85cb3e14d0b
Archive: /Library/Caches/Homebrew/scons-2.3.4.yosemite.bottle.1.tar.gz
To retry an incomplete download, remove the file above.
Warning: Bottle installation failed: building from source.
==> Downloading https://downloads.sourceforge.net/scons/scons-2.3.4.tar.gz
######################################################################## 100.0%
Error: SHA1 mismatch
Expected: 8c55f8c15221c1b3536a041d46056ddd7fa2d23a
Actual: a2fd3379ea944f6b2f97fb0f79b7b85cb3e14d0b
Archive: /Library/Caches/Homebrew/scons-2.3.4.tar.gz
To retry an incomplete download, remove the file above.
I also found this github issue https://github.com/Homebrew/homebrew/issues/28844, but I don't have any expired certificates in my keychain. Any help is appreciated!
I've just had the same issue. It appears to be temporary, as the SourceForge website is partially down.
The sourceforge.net website is temporarily in static offline mode.
Only a very limited set of project pages are available until the main website returns to service.
I imagine the issue will be resolved shortly and you will be able to retry in a couple of hours. There may be updates posted to https://twitter.com/sfnet_ops although there isn't currently any information on this particular outage.
We are developing an application using tomcat and jersey.
Within this webapplication we need to connect to a https Website with a valid, not expired certificate.
If I do connect to this website locally via my chrome browser, everything works fine!
Unfortunately the tomcat server with our webapp throws an exception. We are using the Apache HttpClient (4.0) to connect to the https site:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The server certificate is absolutely valid and from thawte.
Three different online tools validated the certificate successfully.
Openssl has an issue, too and showing me three certificates but throwing a simple error:
Verify return code: 20 (unable to get local issuer certificate)
The problem with openssl seems to be that it uses the wrong path /usr/lib/sslinstead of /etc/ssl/certs. If I use the CApath argument pointing to the proper path, openssl works fine so may this be an issue with the httpClient?
So our code for the default client is quite simple:
client = new DefaultHttpClient();
response = client.execute(url); //this throws the exception
EntityUtils.consume(response.getEntity());
It's not an option to allow any certificates by implementing a custom TrustedManager!
Futher I read, that some CA's are not part of the JDK/JRE and so it's certificates should be imported manually into the keystore or use a custom one, but thawte is a well known CA and shouldn't it work on default?
EDIT
I did set the javax.debug properties in catalina.sh so that I have further information about the problem:
http-bio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: basic constraints check failed:
pathLenConstraint violated - this cert must be the last cert in the certification path
I would appreciate any help!
Thanks in advance!
Okay, I got it working!
Although thawte is a well known CA it seems that Java SSL did have some problems with it.
After downloading the ssl Certificate via openssl:
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
and saving it into an pem file, I did the manual import into the java keystore:
keytool -import -alias myAlias -file theCert.pem -keystore lib/security/cacerts
I have no idea why java ssl was not able to validate the thawte certificate properly.
Listing the keystore showed me, that there are 7 thawte trusted certificates in the standard keystore but bizarrely it did not work until I manually imported the pem file
I am trying to understand your setup. You have a SSL certificate (issued by Thwate), installed in tomcat and you can access your site just fine over SSL using say IE or Firefox or Chrome.
But when you try to access it using HttpClient, you receive the above error ?
Is that correct ?
The error clearly indicates that your client does not trust the CA. But if the cert is signed by Thwate (and is installed correctly and is acessible via IE/Firefox etc), then it should work fine.