I am building a JAVA web service client in which i connect to a service.
This service has a ssl certificate verification.
How to call this service using ssl certificate verification.
I am using JAX-RPC implementation in client built using Eclipse.
An example would be appriciated.
I am able to do the web service connection...
I added the key store using the command:
keytool -import -trustcacerts -file <file path/filename.cer> -alias <aliasName> -keystore <JAVA_HOME/jre/lib/security/cacerts>
gave the password as "changeit" and added the certificate in keystore.
Now in code i added two lines:
System.setProperty("javax.net.ssl.trustStore", "<JAVA_HOME>/jre/lib/security/cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
also added
_call.setUsername("username");
_call.setPassword("password");
where _call is the call object of Call Class.
And it worked!!!!!!
All you need to do is injecting the server root certificate to your JDK/JRE environments by using the following command line: -
keytool -importcerts -trustcacerts -file <path_to_root_cer_file> -alias <the_server_alias> -keystore <your_keystore>
The default [your_keystore] is
1. <JDK_HOME>/jre/lib/security/cacerts
2. <JRE_HOME>/lib/security/cacerts
The default password is changeit.
When you call the web service, just mention the
"https://<host>:<SSL_port>/Path/To/Services"
I hope this may help to achieve your requirement.
Regards,
Charlee Ch.
You mean your web service is protected with a "client certificate"? If yes, get the certificate in either a .p12 (PFX) or keystore format from the service provider and use the following System properties to set it before your call:
javax.net.ssl.keyStore - Path to the keystore on your server
javax.net.ssl.keyStorePassword - passphrase for that keystore
javax.net.ssl.keyStoreType - Set it to "pkcs12" is the client certificate provided to you is .p12
If you application is client to only one web service provider, set these properties as VM arguments, if not, you may need to create specific SSLConnectionFactory for each secured endpoint. Refer to my response on this post for details on creating custom SSL Socket Factories.
Related
I have an instance of Apache ActiveMQ 5.16.3 with Java 8 in a Debian Docker container (Kubernetes).
It's configured to use mutual SSL in /opt/activemq/conf/activemq.xml:
<sslContext>
<sslContext
keyStore="/etc/data/my-bridge-broker.ks"
keyStorePassword="my-pass"
trustStore="/etc/data/broker_to_client.ts"
trustStorePassword="my-pass"
/>
</sslContext>
<!--- ... --->
<transportConnectors>
<transportConnector name="ssl" uri="ssl://0.0.0.0:61714?transport.enabledProtocols=TLSv1.2&transport.needClientAuth=true"/>
</transportConnectors>
The mutual SSL works properly, and I am able to connect from a sample Java client, using ActiveMQSslConnectionFactory providing the appropriate certificates in the truststore and keystore and passwords.
Next, while the broker was running I removed the client's certificate by its alias from the server's trust store:
cd /etc/data
keytool -delete -alias <client-cert-name> -keystore broker_to_client.ts -storepass my-pass
Surprisingly, the client is still able to connect. I restarted the server and the client can still connect and post messages on the queues. Any idea why? I thought the truststore defines which client certificates will be allowed?
Looking at the documentation they recommend using Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). They don't mention the option to remove from the truststore. Does this mean ActiveMQ doesn't use the truststore file?
If the client's certificate is issued from a trusted authority then it doesn't matter if the it's in the broker's truststore. The client's certificate will still be trusted because it's from a trusted authority. The broker's truststore is only there to include certificates that come from an untrusted authority or are self-signed.
My Java application needs to authenticate to Google cloud Mysql instance with SSL client authentication. Its client-key and certificate are provided by Google. I also need to setup JMX agent with SSL on same application whose certificates are provided by a private CA.
How to prevent Mysql from presenting JMX certificate and vice-versa in case I add both private certificates into single keystore provided to JVM at startup
Is there any other way to authenticate SSL certificates with Mysql beside putting then in 'javax.net.ssl.keyStore'? If not, are there any aliases that Mysql or JMX agent prefer over other names?
You can look at using the Cloud SQL MySQL socket factory which uses temporary SSL certificates to authenticate to Cloud SQL (only supported for Second Generation instances):
https://github.com/GoogleCloudPlatform/cloud-sql-mysql-socket-factory
MySQL Connecting Securely Using SSL
For SSL support to work, you must have the following:
A JDK that includes JSSE (Java Secure Sockets Extension), like JDK-1.4.1 or newer. SSL does not currently work with a JDK that you can add JSSE to, like JDK-1.2.x or JDK-1.3.x due to the following JSSE bug: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4273544
A MySQL server that supports SSL and has been compiled and configured to do so, which is MySQL 4.0.4 or later. For more information, see Building MySQL with Support for Secure Connections.
A client certificate (covered in this section)
How to work with multiple keystore?
The test certificates reside in keystores named node1.keystore … node100.keystore, which were created following the steps described in Creating Self-Signed Test Certificates.
Export the test certificate for node1.example.com:
$ keytool -exportcert -keystore node1.keystore -alias node1 \
-storepass changeme -file node1.cer
Import the test certificate into the custom truststore:
keytool -importcert -keystore custom.truststore -alias node1 \
-storepass trustchangeme -file node1.cer -noprompt
Here we specify the -noprompt option to suppress the prompt asking
you to confirm that the certificate is trustworthy. Since you
created the certificate yourself, this confirmation is unnecessary.
Repeat Steps 1 and 2 for node2.keystore … node100.keystore.
Resource Link:
Creating Java Keystores and Truststores
Keystore and truststore details:
A keystore is used in one of two distinct ways:
The keystore contains private keys and certificates used by TLS/SSL servers to authenticate themselves to TLS/SSL clients. By convention, such files are referred to as keystores.
When used as a truststore, the file contains certificates of trusted TLS/SSL servers, or of Certificate Authorities trusted to identify servers. There are no private keys in the truststore.
Because keystores contain private keys, while truststores do not, the security requirements for keystores are more stringent. In particular:
Hadoop TLS/SSL requires that truststores and the truststore password be stored, in plaintext, in a configuration file that is readable by all.
Keystore and key passwords are stored, in plaintext, in a file that is readable only by members of the appropriate group.
These considerations should inform your choice of which keys and certificates to store in the keystores and truststores you will deploy across your cluster.
Keystores should contain a minimal set of keys and certificates. A reasonable strategy would be to create a unique keystore for each host, which would contain only the keys and certificates needed by the Hadoop TLS/SSL services running on the host. In most cases, the keystore would contain a single key/certificate entry.
Modifying Keystores: CDH services and processes must be restarted in case changes are made to a keystore. However, this is relatively rare since keystores do not need to be updated when hosts are added or deleted from a cluster.
Because truststores do not contain sensitive information, it is reasonable to create a single truststore for an entire cluster. On a production cluster, such a truststore would often contain a single CA certificate (or certificate chain), since you would typically choose to have all certificates issued by a single CA.
Important: Do not use the same password for truststores and keystores/keys.
Since truststore passwords are stored in the clear in files readable by all, doing so would compromise the security of the private keys in the keystore.
I am new to web service. I have given a task to write a client code which will call a authentication web service which is exposed on https. I need to pass username and password from client code to check for valid user. I also have keystore and trustore file. I don't know how to use these files. Can anyone please guide me and provide a sample client code?
I am using Axis to generate client stub from wsdl.
Regards,
Vishal
When you say Webservice and Axis, I think you are talking about SOAP. You may want to check Java webservice (soap) client - use certificates.
SOAP is a protocol over HTTP. If you want it to be over SSL it would be on HTTPS.
If you are working on RESTful implementations of JSR-311 like CXF, jersey etc, you will find examples in their websites.
If you can access the URL then you need to add the certificate.
Access the URL and click on the lock icon to view the certificate.
Go to the details tab of the certificate and save certificate in Base64 .cer format
Install the certificates
Execute the following command
The command:
$ keytool -import -noprompt -trustcacerts -alias ALIASNAME -file FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -storepass PASSWORD
Reference:
http://docs.oracle.com/javase/tutorial/security/toolsign/rstep2.html
axis1 or axis2?
anyway.. if it's just https, you need to import the certificate and depending on the policy of the server you are calling you might have to present yourself with a certificate too.....
look here https://axis.apache.org/axis2/java/rampart/samples.html for information and an example on basic auth..
As for adding a certificate to the outgoing request you need to do something along these lines:
System.setProperty("javax.net.ssl.trustStoreType", "JKS");
System.setProperty("javax.net.ssl.trustStore", "keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "password");
System.setProperty("javax.net.ssl.keyStoreType", "pkcs12");
System.setProperty("javax.net.ssl.keyStore", "client.p12");
System.setProperty("javax.net.ssl.keyStorePassword", "password");
Take additional care if your communication is going through a proxy..
I need to send a POST request to a server that uses some levels of security. Unfortunately I don't know much about self signed certificates, I never used or studied it.
In the developer guide of the service it sais that the server uses a "public 1024-bit self signed certificate".
What does it mean? I've to create a certificate or I've to ask for it?
If i've to create a certificate, then how I should use it?
I'm implementing the client in Java
You need to download the certificate e.g. with your internet browser. Click through the security information and export the certificate.
Then you need to import it into your local java keystore so that the JVM can find it. For import use the keytool which you find in your jre/bin directory. Documentation for the keytool: http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/keytool.html
The default keystore is jre/lib/security/cacerts.
Then you can import the downloaded certificate:
jre/bin/keytool -import -keystore jre/lib/security/cacerts -alias mycertificate -file downloads/mycertificate.cer
Hope this helps.
P.S. If it is self signed or verified its not important at this point. Just you (your client) must trust it.
I want the last of these lines in a standalone application to pass with no exceptions thrown:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",
"weblogic.jndi.WLInitialContextFactory");
props.setProperty("java.naming.provider.url",
"t3s://localhost:9002");
props.setProperty("java.naming.security.principal",
"<username>");
props.setProperty("java.naming.security.credentials",
"<password>");
Context ctx = new InitialContext(props);
...but I get this information in an exception:
Warning Security BEA-090542 Certificate chain received from localhost - 127.0.0.1 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.
So, I created a keystore for the ca using this command:
keytool -keystore client.jks -importcert -file cacert.pem
...and referred to it using the property weblogic.security.TrustKeyStore=client.jks
This still doesn't work, most likely because I haven't supplied a password to the keystore. What have I missed? How can I supply this password? (or, how do I create the keystore without setting a password for it?)
Almost two months later, I returned to this issue. After finding this link, I found out that this works:
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification","true");
System.setProperty("java.protocol.handler.pkgs", "weblogic.net");
System.setProperty("weblogic.security.TrustKeyStore","CustomTrust");
System.setProperty("weblogic.security.CustomTrustKeyStoreFileName", "<keystorelocation>");
System.setProperty("weblogic.security.CustomTrustKeyStorePassPhrase","<keystorepassword>");
System.setProperty("weblogic.security.CustomTrustKeyStoreType","JKS");
I only got it working using system properties.