Following up from previously asked question.
We were provided with an x.509 v3 .pkcs12 certificate from Bloomberg.
For testing the webservice on Coldfusion, the certificate had to be encoded to DER for installing in the keystore.
I managed to install the certificate successfully using the link.
But getting the following error when calling the webservice.
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Testing the same(.der) certificate on SoapUI threw the below error.
ERROR:java.security.KeyStoreException: failed to extract any certificates or private keys - maybe bad password?
Note: The provided .p12 and the converted .pem certificates work as expected on SoapUI.
Any pointers?
Related
I'm working on a gRPC service, and we're using a CA certificate we generated ourselves for our server. Unfortunately, I can't seem to figure out how to tell grpc_cli about that certificate, and so I get "Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed."
I see an option for specifying the client cert and key, but not for the CA cert. What am I missing?
I am trying to connect to https site from jmeter and I am getting the below response data in the View Results Tree:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
To connect to the https site there is a certificate which can be exported to .cer format. I tried exporting the certificate and then adding it to Jmeter_home\bin and installing it. Also from Jmeter Option->SSL Manager I selected the certificate. But the above attempts didn't work.
JMeter doesn't understand cer format, as of current version (4.0) it supports the following formats:
JKS
PKCS12
You can convert the certificate using Keytool or OpenSSL. Once done you can add javax.net.ssl.keyStore system property pointing to the .jks or .p12 certificate and your outgoing requests will be encrypted. More information: How to Set Your JMeter Load Test to Use Client Side Certificates
My application invokes a web service request. The provider of this web service is requesting for a certificate based authentication.
Unfortunately while making the handshake, the certificate is not being returned as part of the CertificateRequest step. Below is the log trace
Cert Authorities:
<Empty>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client
authentication
I have placed the keystore and the truststore using the below properties which is being picked up during the handshake (logged in the logs)
-Djavax.net.ssl.keyStore=$CMX_SSL_KEY_STORE
-Djavax.net.ssl.keyStorePassword=123456
-Djavax.net.debug=ssl
-Djavax.net.ssl.keyStoreType=pkcs12
JAVA_OPTS= JAVA_OPTS="-D$PS_TOKEN$ENV_TOKEN $LOCAL_MEM_OPTS $GC_OPTS
$CMAX_OPTS $JMX_OPTS $CMX_SSL_TRUST_STORE_OPT $MQ_OPTS
$ADDITIONAL_JVM_OPTS $LOCAL_JVM_OPTS $CMX_SSL_KEY_STORE_OPT"
I don't have a private key as part of the keystore, as the vendor who provided the certificate refused to provide the private key. As part of the keystore, I have the whole chain of the certificate, but still its not working
Error seen in the logs is as below
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
Need some guidance to resolve this issue
I looked at
why doesn't java send the client certificate during SSL handshake?
which is on the same problem, but the solution provided by Bruno is failing. Not able to attach the certificate to the private key using the same alias
I don't have a private key as part of the keystore
Then you don't have a keystore: you have a truststore.
as the vendor who provided the certificate refused to provide the private key.
Of course he did. None of your beeswax.
You're supposed to provide your own private key and certificate in your own keystore.
You have a serious misunderstanding here.
I got a secure cluster NIFI with 3 nodes, configured with truststore.jks and keystore.jks
In my invokeHTTP, i've set "StandardSSLContextService" with keystore and trustore for https.
invokeHTTP works when i'm trying https://nifi:9443/nifi-api/controller/config
but not works when i'm trying "https://auth_server/oauth/access_token"
So when I'm trying use invokeHTTP to get token but it failed with this error :
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
thanks for helps
The StandardSSLContextService can be configured with a truststore, which is a Java KeyStore object which contains a collection of TrustedCertEntry objects -- each of which holds the public key and certificate information of a trusted entity. When Apache NiFi attempts to contact some other endpoint or service over HTTPS, it evaluates the received certificate identifying the service and attempts to validate that certificate. If the endpoint certificate is not directly contained in the truststore, it checks to see which certificate signed the leaf cert, and validate that one. This process continues up the certificate chain until either a cert is found that is trusted, or none are.
The error message you are receiving is stating that none of the certificates in the chain could be verified. As daggett pointed out, you could manually import the certificate of the service you want to validate into a custom truststore. If this is a service available on the public internet and signed by a generally trusted certificate authority (CA), you can also point your StandardSSLContextService to the default list provided by Java. The cacerts truststore is included automatically, and has a similar trusted entry list to modern browsers. It is found in $JAVA_HOME/jre/lib/security/cacerts. You can determine the value of $JAVA_HOME for your OS and Java version.
Truststore filename: /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts (example)
Truststore password: changeit (default value)
Truststore type: JKS
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.