Installing Partner's Key+Certificate (PFX) in weblogic for outbound https connection - ssl

We had a requirement to Integration with external partner from SOA over HTTPS. For this partner had provided us their Key Pair (in form of pfx file).
When we imported the pfx file in SOAP UI and tried to connect with partner URL, it works absolutely fine.
But when we are importing the partner's key and certificate in weblogic (we are using identity and trust jks), we get below error:
Error:
summary=oracle.fabric.common.FabricInvocationException: Unable to invoke endpoint URI "https://www7.aeat.es/wlpl/SSII-FACT/ws/fe/SiiFactFEV1SOAP" successfully due to: javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Message send failed: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
,detail=Unable to invoke endpoint URI "https://www7.aeat.es/wlpl/SSII-FACT/ws/fe/SiiFactFEV1SOAP" successfully due to: javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Message send failed: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
,code=null}
We've followed below steps to import partner's key and certificate in weblogic:
Steps followed to import partner key and certificate:
Partner has provided us pfx file which contains private key and
certificate.
Export key from PFX provided by Partner:
openssl pkcs12 -in LuisEmail.pfx -nocerts -out LuisEmail.key –nodes
Export certificate from PFX provided by LUIS: openssl pkcs12 -in LuisEmail.pfx -nokeys -out LuisEmail.cer –nodes
Copy LuisEmail.cer to windows and create root.cer and inter.cer by manually exporting.
Create chain by combining all 3 certs in order: intermediate-root-server and save it as .pem file.
Bring the pem file to linux machine.
Set environment to execute java util.importPrivateKey utility . /apps/oracle/product/fmw/wlserver_10.3/server/bin/setWLSEnv.sh
Convert private key file into rsa private key file: openssl rsa -in LuisEmail.key -out LuisEmail_RSA.key
Import pem/key in identity store: java utils.ImportPrivateKey -keystore netappidentity_STA.jks -storepass -storetype JKS -keypass
-alias staPrivateKey -certfile
LuisEmailChain.pem -keyfile LuisEmail_RSA.key -keyfilepass
Import Root CER file in trust store: keytool -import -v -noprompt -trustcacerts -alias starootcert -file LuisEmailRoot.cer -keystore netapptrust_STA.jks -storepass
Restarted Servers
Any pointer on what we are missing here would appreciated! Please not that when we examine the pfx file using keytool explorer, we see only private key and server(domain) certificate. There are no intermediate and root certs.
Also anyone know why Partner's would give us Key Pair and if it will be a 1-way ssl or 2-way ssl. We were under impression that only public certificates are exchanged for ssl communication.
Thanks.

We were able to figure out the issue here. Since our partner was a government tax agency (I suppose they did not want to trust our CA), they provided us a key pair (having private key). We were supposed to use it as our own key.
We imported the private key in our identity store and certificate exported from their URL in trust store and connectivity worked fine.
Thanks

Related

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.

SSL certificates in Codename One using Simulator

I created a custom SSL certificate through Java keytool command, in order to test the connection from my Codename one app and my HTTPS REST web service.
This is the complete command:
keytool -genkey -alias my_alias -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650
When the app (running on the simulator) tries to interact with the web service, it returns the following exception:
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 read here
and I understood for a real mobile device is possible to add the custom certificate.
My question is: using the simulator, how can I do? How can I use my "home-made" certificate?
There is really no reason to do this anymore. You can but if you just don't want to pay for a certificate you can just use "lets encrypt" and it will work: http://letsencrypt.org/
Notice that it requires a recent version of JDK 8 (I think 128 or newer).
SSL will only work with proper domains and not with IP addresses etc.

Issue to install Geotrust certificate (SSL) on Tomcat

I got a certificate from Geotrust and I'm trying to apply it to my Tomcat web server, as can be seen in the image below, I left .csr and .p7b in the same directory (java / bin)
the softlayer support team, has indicated the link https://www.digicert.com/ssl-certificate-installation-tomcat.htm as help and when I execute the command I get the error:keytool error: java.lang.Exception: Input not an X.509 certificate
Anyone have been through this and can you help me? I've been trying to figure it out for days.
Reasons for the error :-
You are importing the certificate (p7b) in a wrong keystore . when you import the certificate in an existing keystore it will never ask you to punch in the password twice. If its asking you to punch in the password twice, it means its creating a new keystore. In a new keystore, you cannot import the the certificates as private entry You can only create Trusted Entry and add the certificates as trusted.
Solution
1)If you have the private key with you, please create a text file and rename the file as example.pem with all the certificates and private key in it in the below sequence
a) private key
b) Server certificate
c) Intermediate Certificate
d) Root Certificate.
2) Run the below openssl command
openssl pkcs12 -in example.pem -out certificate.pfx
3) As you have the pfx file from the above command, use the keytool command below to convert this in jks format for tomcat
keytool -importkeystore -srckeystore certificate.pfx -srcstoretype
pkcs12 -destkeystore certificate.jks -deststoretype jks.
4) Provide the certificate.jks directive in server.xml file of tomcat along with its password
5) Restart the tomcat service.
Hope this helps ..

Configuring Glassfish as a client of web services using mutual SSL

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.

Client SSL authentication causing 403.7 error from IIS

I'm trying to connect to a web service (not under my control) configured to authenticate users via SSL client certs. I have a valid certificate in PKCS12 format containing the client certificate and associated private key. The certificate is issued by a CA accepted by the web service provider.
Installing the certificate and trying to access the restricted area in various browsers gives the following results:
IE6 - Works fine and I can retrieve the WSDL
IE7 - Prompts for the certificate but then fails with a 403.7 from the server
Firefox3 - Set to ask, but no prompt and fails with a 403.7
Safari 4 - Certificate is installed in the Keychain, but no prompt and a 403.7
Also, trying to access the web service programmatically (Java) fails with the same 403.7 error code.
Strange that this works in IE6 but in no other browser, what am I missing? Do I need to include the full CA certificate chain in the PKCS12 file?
Any help would be greatly appreciated.
This really works! If you're confused by the -inkey and -in options, they are the private key and certificate from the p12 file. You can convert the p12 file to pem format with:
openssl pkcs12 -in file.p12 -clcerts -out file.pem
and use the above command with "-in file.pem" only.
Also, you can import the root CA cert into your trusted certs store, here is the description how to do that: http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl, and then you don't have to manually copy the certificates. After installing the cert use the command above without the "-CAfile chain.pem".
Ok, got this working. The answer is yes, I did need to include all intermediary CA certs in the PKCS12 file. I concatenated all the intermediary CA certs plus the Root CA cert in the file "chain.pem" then executed the following command:
openssl pkcs12 -export -chain -CAfile chain.pem -in cert.pem -inkey key.pem -out cert.p12