I have a jks file that has a CN mapped with a DNS like *.example.com. I am trying to use this JKS file to set up SSL on a windows setup with hostname as 'sample-hostname'. When I am using the jks file on this setup, I am receiving the following error:
Caused by: java.security.UnrecoverableKeyException: Cannot recover key
I read online that my hostname should match with the CN in the jks file. How can I achieve this on a windows setup? I am a newbie in the whole SSL stuff. Please help!
Related
I'm trying to enable SSL on SOLR with a SAN cert - I ran the keytool.exe to generate the .jks file from the cert file. That process went fine. I copied the .jks file over to the /etc directory, and then I enabled SSL in solr.in.cmd file. Then when I try to access the site, it tell me: "The client and server don't support a common SSL protocol version or cipher suite." Is the issue with the cert, or issue with the way I generated the .jks file? Any help with this would be appreciated.
MORE INFO:
I learned that .cer files only contain the public key, and the private key is on the machine that generated the CSR. However, in this case, the machine that the cert is installed on is probably not the machine that the CSR was generated in. So, given this situation, how do I generate the keystore file to be used in SOLR?
I use GF 3.1.2.2 and now I need to configure a Lets Encrypt SSL certificate for my webapp. After I changed the default keystore.jks with the new including the Lets Encrypt cert, my webapp worked fine, but Admin Console no.
The server.log file arises this error because it needs the default keytore.jks file:
[#|2016-05-17T11:31:15.344-0400|SEVERE|glassfish3.1.2|org.glassfish.admingui|_ThreadID=72;_ThreadName=Thread-2;|javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target;
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target;
restRequest: endpoint=https://localhost:4848/management/domain/anonymous-user-enabled
attrs={}
method=GET|#]
I am 3 years late, but who knows maybe someone reads it anyway :)
The reason for your problem is that the certificate the admin-listener uses, is not within your new keystore.
The default certificate the admin-listener (Port 4848) uses has the Alias-Name 's1as' and is provided with the Glassfish installation.
This certificate is within the Default-Keystore keystore.jks.
If you changed the keystore with a new one, then Glassfish can't find the certificate he uses for the admin-listener.
This is most probably the solution to your problem:
Easy one:
Stop glassfish
Go to domain.xml in Path ./glassfish/glassfish/domains/domain1/config and whereever you find an attribute with the name 'cert-nickname' change the value to the Alias-Name of your Let's Encrypt Certificate.
Restart Glassfish
Harder but more sophisticated:
Find out which certificate your admin-listener used before.
For that temporarily change back to your old keystore.jks.
Login into the
Admin console and go look for the Certificate NickName under
/Configurations/server-config/Http-Service/Http-Listeners/admin-listeners.
The default certificate Glassfish uses has the Name s1as.
a) If its a fresh Glassfish installation and the admin-listener still uses the default certificate s1as then i would suggest you switch over to your new Certificate.
Just change the Certificate NickName to the Alias-Name of your Lets' Encrypt certificate and click the save button.
Stop Glassfish
Switch over to your new Keystore
Start Glassfish
b) If you insist on keeping the old certificate then you have to extract it from your 'old' keystore via keytool and import it into your new keystore.
Stop Glassfish
Extract the old certificate with this command:
keytool -export -alias myOldCertificateNickname -keystore keystore.jks -file myOldCertificate.crt
Replace myOldCertificateNickname with the Certificate NickName you found in Step 1!
Import your freshly exported old certificate into your new keystore
keytool -import -alias myOldCertificateNickname -file myOldCertificate.crt -keystore myNewKeystore.jks
Start Glassfish
Now this is most important!!
For all this to work you need to know the password for both keystore's and the certifcates as well! And the MasterPW of Glassfish too!
Because Glassfish insist that all 3 Passwords have to be the same (MasterPW, Keystore Password, Password for the certificate)
And here a really good online guide for Installation of certificate in Glassfish
https://www.ssls.com/knowledgebase/how-to-install-an-ssl-certificate-on-glassfish/
I have a xmpp server (openfire 3.9.3) and trying to secure my non-ssl connection to ssl connection.
that's why i have created a self-signed certificate using java keytool as
keytool -genkey -keystore keystore -alias example.com
and i filled the several pieces of information required for the certificate.
the certificate successfully created. and i configured my server to access the keystore file but when restart my xmpp server it says
Unable to access certificate store. The keystore may be corrupt
what should i do for fixing the same issue ?
thanks in advanced
You can :
Delete certs in AdminWEB interface.
Restart openfire
Delete /opt/openfire/resources/security/keystore file
Generate new cert from web interface.
References : http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ssl-guide.html
Hope this help...:)
I'm trying to configure SSL on my local development machine so my adapters will be able to connect to the Bank-end service.
Our Back-end service team provided us with the following information:
ssl.keystore.path=conf/mobile.p12
ssl.keystore.type=PKCS12
ssl.keystore.password=PASSA
SSL ALias = AlIAS
SSL Password = PASSA
They send to use the "mobile.p12" file.
I added those configuration to my worklight.propeties:
# Worklight SSL keystore
#######################################################################################################################
ssl.keystore.path=conf/mobile.p12
#SSL certificate keystore type (jks or PKCS12)
ssl.keystore.type=PKCS12
#SSL certificate keystore password.
ssl.keystore.password= PASSA
In my Adapter.xml I added the following:
<sslCertificateAlias> AlIAS </sslCertificateAlias>
<sslCertificatePassword> PASSA </sslCertificatePassword>
When I deploy the project on my local Machine and try to login in the app through one of our adapters, I'm getting this error:
[ERROR ] FWLSE0152E: Unable to find certificate chain with alias: 'AlIAS' [project MobileBanking]
I tried to import the certificate to the default.keystore inside server > config by:
keytool -importkeystore -srckeystore mobile.p12 -destkeystore default.keystore -srcstoretype PKCS12
the result is :
Import command completed: 0 entries successfully imported, 0 entries failed or cancelled
which indicated it didn't work since 0 entries.
after running the keytool command, the error changed when I click login in our application to be :
Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
which indicated that my configuration is wrong.
What am I missing?
thanks.
Based on the type of your certificate (un-signed, self-signed, CA-issued), make sure you are following the instructions from: Configuring Worklight Server
Specifically:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/t_configuring_SSL_WL_adapters_backend_servers_certificates.html
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/c_ssl_config.html
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.