Configuring Glassfish as a client of web services using mutual SSL - authentication

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.

Related

Can't build keystore: [Private key missing (bad password?)] - SOAPUI

I got a serious problem while making an SSL request to the server with SOAPUI. I am a newbie in SoapUI and maybe I did something wrong while I'm trying to import the certificate into SOAPUI.
My client sends me:
Root CA
Intermediate CA
SSL CA
Private Key
I am using keytore to generate keystore with password by command
keytool -genkey -alias soapui -keyalg RSA -keystore soapui.keystore
And then I tried to export the this keystore with my SSL CA
keytool -export -alias soapui -file SSL.cer -keystore soapui.keystore
And then I import this into Keystores in the SoapUI.
However, I got the error
ERROR:java.security.KeyStoreException: Can't build keystore: [Private key missing (bad password?)]
I have no idea where am I wrong?
Could anyone please indicate what are the steps I should work on to make the SSL request to SoapUI?
Please help
Thank you.
I assume you need to make a Two-Way SSL connection with client cetificate.
Firstly you need to make a keystore (JKS) containing:
your private key
all certificates upwards including the root CA
Maybe using https://keystore-explorer.org/ may help you to understand and verify the content of your keystore.
There are multiple ways to configure the client certificate in SoapUI:
If you use the global configuration (File - Preferences - SSL Settings), there is only one password to be set. Make sure your keystore password and key password are equal.
If you use the setup on the project level, you are allowed to enter two passwords.

JMeter Ignore SSL Security Certificate

I am getting the following error while trying to connect to LDAP Server.
Is there a way to Ignore SSL Security Certificate. I am able to connect to the server outside of JMeter using other tools.
Thread Name: Thread Group 1-1
Sample Start: 2018-09-23 12:16:48 EDT
Load time: 154
Connect Time: 0
Latency: 0
Size in bytes: 555
Sent bytes:0
Headers size in bytes: 0
Body size in bytes: 555
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 800
Response message: javax.naming.CommunicationException: x.x.x.x:1636
[Root exception is 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]
Response headers:
SampleResult fields:
ContentType: text/xml
DataEncoding: UTF-8
the best (and most common) way to solve this is to trust the LDAPS server, i.e. add the server's certificate to JRE's cacerts file using keytool. There is already an s-o answer on how to do this (here: Is there a java setting for disabling certificate validation?) - the gist is (taken from there)
cd %JRE_HOME%
keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore ..\lib\security\cacerts -file your.crt
When you don't have the public key (certificate file) yet, you can e.g. get it by connecting to the LDAPS server with Apache Directory Studio (https://directory.apache.org/studio/) which stores all public keys of LDAPS servers you trust. The exact routine was described on the mailing list already (here: http://mail-archives.apache.org/mod_mbox/directory-users/201004.mbox/%3C4BBF6471.6040900#apache.org%3E), so I'm just giving the gist (again largely taken from there)
find ~/.ApacheDirectoryStudio -name \*.jks # gives you the keystores managed by DirectoryStudio
keytool -list -keystore path/to/permanent.jks
keytool -exportcert -alias <aliasname> -keystore path/to/permanent.jks -file your.crt
Most probably it indicates the issue with your LDAP server SSL setup, i.e. one of certificates in chain cannot be checked against authority. I would recommend double-checking the certificate chain using i.e.
OpenSSL tool like: openssl s_client -showcerts -connect yourhost:yourport
SSLPoke tool like: java -Djavax.net.debug=ssl SSLPoke yourhost yourport
You have 2 ways:
Add the certificate into the JVM truststore like:
keytool -import -file your_ldap_certificate -alias certificate -keystore trustStore.keystore
Create a custom class which will be trusting all the certificates and set java.naming.ldap.factory.socket system property to point to that class (the class must be in the JMeter Classpath)
Just in case if you need more information on LDAP servers performance testing with JMeter check out How to Load Test LDAP with Apache JMeter™ article.

Glassfish Admin Console stopped after change keystore.jks

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/

How to add SSLC certificates in a unix server

I have a java web project and I have used few certificates to contact a URL. Now I have deployed project as a WAR file in a Unix server and my project has a certificate issue.
I have the certificates in my local store and I need to put them in the Unix server and need to add them to the keytool in Tomcat. How do i do that.
Can I get an example how do I do that with keytool?
There are at least 3 ways of handling this problem:
You can import the certificate into the JRE's default truststore (often in $JAVA_HOME/lib/security/cacerts). This will affect all the applications using that JRE (unless they override the default settings). You'll need to have write permissions on that cacerts file to do this too.
You can import the certificate into a local keystore that you will configure to be Tomcat's default truststore. Typically, you could make a copy of the default cacerts file and import your certificate into this copy, or you can create a new keystore and import only the certificates you know you need (keytool -import -keystore ... will create the keystore file if it doesn't exist). This can be done in tomcat by setting an additional system property in catalina.sh (or .bat): in JAVA_OPTS, you can add -Djavax.net.ssl.trustStore=/path/to/local/truststore.jks for example (and other related properties).
You can make that certificate be used only by certain connections in your application (or set the default SSLContext programmatically). For this, you'll need to alter your application so that it loads the keystore, uses it to initialise a TrustManagerFactory, in passed into an SSLContext. Then, how that SSLContext can be used depends on the client library you're using. There is an example in this answer.
Either way, you can import your cert (be it a CA cert or a specific server cert) into the truststore of your choice using:
keytool -import -file cert.pem -alias "some name" -keystore truststore.jks
(If using the programming route, you can also create your keystore in memory and load the certificate file dynamically, as shown in this answer. Using keystores might be easier, it's up to you to assess the pros and cons of the deployment you want to use.)
I got the answer for this. We need to find which java file the tomcat is using and we need to add the keytool to that particular thing.
this is where the tomcat has its cacerts .ie. the java which is used by the tomcat.
etc/pki/java/cacerts
Keytool command:
keytool -import -alias ttg-lys-cm1 -file /var/lib/certificates/ttg-lys-cm1.cer -keystore "/etc/pki/java/cacerts"
Once you do this restart tomcat and it works fine.
Thanks
pradeepa

Can the alias in a keystore be a guid?

I have a problem in regards to Tomcat 6 and certificates. The problem is somewhat similar to this: Tomcat HTTPS keystore certificate.
My task is to get a Jira installation running with an SSL certificate issued by a CA.
To make sure I have got the workflow right I have tried to create a certificate of my own the following way (this works):
Create 'my' keystore
Extract the certificate from the 'my' keystore
Import the extracted certificate into Java's \cacerts keystore.
This solution works fine - site can be accessed over SSL.
I assume the following can be done with my CA issued certificate, in the form of a pfx file.
I created a new keystore using this command:
keytool -importkeystore -srckeystore certificate.pfx -srcstoretype pkcs12 -destkeystore \mydest\keystore.jks -deststorepass changeit
When I list the contents of the new keystore.jks I get one entry; private key with a guid.
I extract the certificate from the keystore. In this operation I am unable to specify an alias.
I import the certificate into the \cacerts keystore.
I then list the concents of the \cacerts keystore and find my new entry. Instead of having a name, the entry is showing the same guid as from the initial (pfx) keystore.
I alter my server.xml file with the new alias (e.g. guid) and keystore file.
However - starting Tomcat gives this error:
Alias name {guid} does not identify a key entry
Question is:
Can a guid be a key name?
If not, what I am doing wrong? :)
I have tried both keystores in the server.xml file, without luck.
New info; when I execute this command I am able to find information regarding the certificate in the \cacerts file:
keytool -list -v -keystore \cacerts -alias {guid}
So it seems that the guid exists. However, Tomcat seems to be unable to find the same key.
Answer is 'yes'.
The origins of my problem was that I had the wrong password for the key from the pfx file. Using the following command I changed the password from the original one to a the standard password (I did this prior to exporting the certificate from the keystore created from the pfx file):
keytool -keypasswd -alias {guid}
Keytool then asked me for old password and new password.
I might have been able to add some sort of configuration in the server.xml file like 'keypassword', but I haven't looked into that.