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.
Related
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.
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.
I am trying to configure Jenkins on Windows with a SLL certificate following these instructions. Instead of using a Digicert certificate, our IT administrator would like to generate a certificate using the Windows AD CS using the certificate snap-in of mmc.
However we cannot figure out how to import the keytool generated csr certificate request into the certificate snap-in.
If I use a certificate with a recreated certificate request in the mmc certificate store, the certificate is rejected with the following message:
keytool -importcert -alias jenkins -file "D:\Temp\jenkins\jenkins.pem" -keystore "D:\Temp\jenkins\jenkins.jks"
Enter keystore password:
keytool error: java.lang.Exception: Certificate reply does not contain public key for <jenkins>
Does anyone know how to create an SSL certificate from the Windows certificate store based on a java keytool created csr certificate request?
I was able to get Jenkins running with SSL and this is what I did.
On the Jenkins Master
In the Certificate Snap-in of mmc, navigate to Certificates (Local
Computer) / Personal.
Right click Personal Folder and select All Tasks / Request New
Certificate...
Confirm the next two Enrollment pages by clicking on Next.
Check a Webserver Active Directory Enrollment Policy.
A Warning Message shows below the Enrollment Policy
More information is required to enroll for this certificate. Click here
to configure settings.
Click on it.
Fill out the Certificate Properties: Subject name: Common name:
[the name of your jenkins server] Alternative name: DNS: [the
name of your jenkins server] Alternative name: DNS: [the full
name of your jenkins server including your domain]Confirm the
page with OK and the following two pages.
Export the Certificate as PFX format Right click on
certificate All Tasks / Export...
Check: Yes, export the private key Check Include all
certificates in the certification path if possible Check:
Export all extended properties Since we are exporting the
private key, we must provide a password Check: Password and
enter your password and password confirmation
Pick a path for your PFX certificate and finish the export.
Export the certificate one more time without a password in the
Base-64 encoded X.509 (.CER) format.
Rename the resulting .CER file into .PEM.
Create a java key store on the Jenkins server with
keytool -genkeypair -keysize 2048 -keyalg RSA -alias jenkins -keystore jenkins.jks
Answer the questions appropriate for your company and organisation.
Import the PFX certificate into the java keystore with
keytool -importkeystore -srckeystore jenkins.pfx -srcstoretype pkcs12 -destkeystore jenkins.jks -deststoretype JKS
Copy the jenkins.jks to secrets directory where Jenkins is
installed (in my case C:\Program Files (x86)\Jenkins\secrets).
Add the certificate to the Jenkins startup parameters:
-Djavax.net.ssl.trustStore=%JENKINS_HOME%\secrets\jenkins.jks
-Djavax.net.ssl.trustStorePassword=[your password for the java key store]
Restart the jenkins service
On the Jenkins Agent
Import the PEM certificate from above into the java keystore from the command line with administrator priviliges:
keytool -import -alias jenkins -keystore "C:\Program Files (x86)\Java\jre1.8.0_161\lib\security\cacerts" -file [your pem file]
Enter the password of the keystore (by
default changeit) Trust this certificate? [no]: yes
Make sure your jenkins-slave.xml in %JENKINS_HOME% does not contain
-noCheckCertificate in the arguments.
Restart the service jenkinsslave-D__Jenkins.
I am reading the tutorial you have mentioned in your post. And I see this sentence:
"if making your own certificate skip steps 3, 4, and 5". Your code seems to be the specified in step 5.
You could try to copy the keystore file to your Jenkins secrets directory as mentioned in step 6.
This link can also be helpful.
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'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.