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/
Related
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...:)
When trying to run tests with arquillian with adminHttps option set to true, got an exception:
Could not connect to DAS on: (...) | java.security.cert.CertificateException: No subject alternative names present
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not connect to DAS on: (...) | java.security.cert.CertificateException: No subject alternative names present
at org.jboss.arquillian.container.glassfish.CommonGlassFishManager.start(CommonGlassFishManager.java:77)
at org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployableContainer.start(GlassFishRestDeployableContainer.java:59)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
The examples which I found were without ssl turned on.
I think that I should import a certificate, but can't find how or if it's realy that problem. Any idea? Thanks for sugestions.
Whilst the accepted answer shows that this problem was due to the use of the containers self signed certificate, it doesn't explain how the problem can be overcome. Hopefully this answer will help anyone having the same problem.
You can import the containers self signed certificate into a keystore using the following command:
keytool -import -alias glassfish -file mycert.cer -keystore truststore.jks -storepass changeit
Change mycert.cer to the location of the certificate file
Change truststore.jks to the location of the keystore you want to use to store the certificate. This can either be a new keystore or an existing one. The storepass parameter is the password for the keystore. If you are using an existing keystore then you will need to specify the password associated with the keystore.
Once you have imported the self signed certificate into the keystore you need to tell the JVM running Arquillian to use the keystore. This can be done by setting the system parameter javax.net.ssl.trustStore to the location of the keystore. For example javax.net.ssl.trustStore=truststore.jks
Problem was caused by certificate. When deploying to another server you should import certificate from that server into current machine (when usins self-signed certificates)
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.
I use spring security to manage login. I've configured spring security to connect to a ldap server which is securized with ssl (ldaps).
This server is a test server and has no valid certificate. When I try to test the login, spring security complains that the certificate cannot be verified (of course!):
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
My question is simple : I don't want to manage any kind of certificate, I would like to deactivate the certificate check and keep using a ssl ldap. How can I do that ?
It sounds like the certificate of the LDAP server is just self-cert rather than invalid.
To me the simplest solution would be to get that certificate and add it to the cacerts trust store in java. Once that's done the code will run without any modifications.
To get the certificate from the server:
$ openssl s_client -showcerts -connect ldapserver:636
The output will contain a number of entries delimited with
-----BEGIN CERTIFICATE-----
aklfhskfadljasdl1340234234ASDSDFSDFSDFSDFSD
....
-----END CERTIFICATE-----
Copy the last certificate entry into a file (ldapca.crt)
Then, add it to the java keystore in $JRE_HOME/lib/security
$ cd $JRE_HOME/lib/security
$ keytool -import -alias ldapca_self_sign -keystore cacerts -storepass changeit -file ldapca.crt
That means, you'll trust the certificate on the LDAP server and are using SSL correctly in your test environment (rather than having some custom code to switch off part of SSL checking).
Once you've done that (once) your code should run without any modifications.
I'm trying to request data from a web service which requires a client certificate to be presented by a client. The server uses SSL for all communications, and uses a self-signed certificate. I gave Netbeans the service's WSDL file and it generated client code with wsimport.
I have no issues when my client code is written in a regular Java application; I set the trust store to the cacerts file containing the server's certificate, set the key store to be a file provided by the server admin in JKS format containing 2 keys - a client private key and the server's public key, build the request object, and send the request.
The problem comes when I move it to an enterprise Java environment. Requirements dictate that the code must be an Enterprise JavaBean inside an Enterprise Archive running on the Glassfish application server. It appears that Glassfish has its own security settings which override the JVM's settings. When the EJB method containing the web service call runs, the SSL negotiation fails: 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. I don't know how to set Glassfish's security settings up like my JVM's settings, can anyone explain Glassfish's security settings? The research I have done has only shown how to set up Glassfish as a web service server, not as a web service client.
I have a .cer certificate file for the server which I added it to my trust store by using Java's keytool to add it to the default cacerts file.
Would it be better to modify cacerts file with InstallCert to include the self-signed certificate, following the steps at http://blog.johnryding.com/post/1548502059/acquire-an-ssl-certificate-for-your-java-programs-in-win?
I have the trust store file, key store file, along with a .cer certificate file and a .p12 browser certificate, stored in $JAVA_HOME/jre/lib/security and $JAVA_HOME/lib/security.
I'm using Netbeans 6.9.1 and Glassfish 3.1 Final. The relevant piece of code is below, copied from my EJB. The exception occurs at the last line.
System.setProperty("javax.net.ssl.trustStore", "C:\\jssecacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
System.setProperty("javax.net.ssl.keyStore", "C:\\userCertificate.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "password");
RequestObject request = new RequestObject;
request.setQuery("some data");
request.setUsername("user");
request.setPassword("pass");
Service service = new Service();
Endpoint port = service.getWebServicePort();
Result result = port.specificWebServiceMethod(request);
I faced the same exception that Jacques Pritchard described above:
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
I solved it importing the root certificate in both cacerts.jks and keystore.jks, using the following commands:
/usr/java/jdk1.6.0_25/bin/keytool -import -trustcacerts -file root_ca.cer -alias rootca -keystore cacerts.jks
/usr/java/jdk1.6.0_25/bin/keytool -import -trustcacerts -file root_ca.cer -alias rootca -keystore keystore.jks
It's important to say that the alias rootca is a name I defined myself to label the certificate. You can choose any name also.
Instead of using the global system properties, you should create a separate SSLContext for your client. Whether or not it runs within a Glassfish server doesn't really matter, then.
Here is a question that should be relevant (about client-certificates for WS): Choosing SSL client certificate in Java
I had this exact problem (with Glassfish 3.0.1).
Here are the exact steps we took to resolve this.
a. Use java keytool command to view the keystore to see what's in it. This is helpful later on to see if there are any changes. The command goes something like
keytool -list -keystore MyKeyStore.jks
b. Convert the pfx to a pem using openssl. Note that I used the correct password for the input pfx and the same password as my java keystore for the pem file output.
openssl pkcs12 -in MyPfxFile.pfx -out MyPemFile.pem
Convert the pem file to a p12 which can easily be imported into a java keystore. Note that I used the same password from my java keystore as I did on the input and output files.
openssl pkcs12 -export -in MyPemFile.pem -out MyP12File.p12
Now I finally import the p12 into my java keystore. Note that I used java 6, java 5 keytool doesn't have support for the -importkeystore argument.
keytool -importkeystore -deststorepass MyPassword -destkeystore PathToMyKeystore/keystore.jks -srckeystore MyP12File.p12 -srcstoretype PKCS12 -srcstorepass MyPassword
You can list the keystore contents here, something like this keytool -list -keystore keystore.jks just to ensure that your new key was imported correctly.
If you're lucky like I am you'll find that starting up your app server at this point will be of no use. You'll see errors like something about pkix path or something about HTTP 403 Forbidden.
The steps used above worked perfectly for Sun Application Server 9.1_1 but not for Oracle Glassfish 3.0.1. I'm thinking this has something to do with the version of JSSE used in ogs 3 compared to Sun App Server or jdk versions. Adding the jvm option below to your ogs 3 domain.xml file should resolve the issue if simply adding the client cert to the keystore didn't.
<jvm-options>-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol</jvm-options>
I did notice that someone said to not use the jvm options statement above but it's part of the fix, don't use it and see if it works, I'll bet it won't. Maybe just changing the handlers is why it works?
Here's where I found the details: http://onjava.com/pub/a/onjava/2001/05/03/java_security.html?page=4
I also stumbled across a final issue (only for ogs 3), if you get fails every now and again I'd suggest finding the InstallCert app (its out there) and give it the following command line parameters:
I was getting these PKIX errors every third attempt at calling the web service.
Hopefully this helped someone else out. These kind of issues really make me want to rip my hair out :)
I finally got it.
Removed all the certs from my keytool.
Command Example : keytool -list -v -keystore keystore.jks -alias mydomain
I converted the cert response from server to bas64 DER and copied them into one file a .PEM, and I uploaded the .PEM into my keytool:
Command Example : keytool -importcert -keystore keystore.jks -alias mydomain -file my.pem
Then I loaded the keystore:
KeyStore myStore = KeyStore.getInstance("JKS");
InputStream keyInputx = new FileInputStream("C:\\myStore.jks");
myStore.load(keyInputx, "xxx".toCharArray());
KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");
keyInputx.close();
/*Enumeration enumeration = myStore.aliases();
while (enumeration.hasMoreElements()) {
String alias = (String) enumeration.nextElement();
System.out.println("alias name: " + alias);
Certificate certificate = myStore.getCertificate(alias);
System.out.println(certificate.toString());
}*/
keyManagerFactory.init(myStore, "xxx".toCharArray());
SSLContext context = SSLContext.getInstance("TLS");
context.init(keyManagerFactory.getKeyManagers(), null, new SecureRandom());
SSLSocketFactory sockFact = context.getSocketFactory();
Lots of references around so be happy to use.