I need to add a trusted cert to the cacerts that come with the JRE, but I do not have control or ownership over my customer's JRE installation. Is there a way to do this through the security APIs other than to assume a file path location for the cacerts file and read it into a custom TrustManager?
I don't recommend setting a trust store globally for the JVM, unless you are running a standalone java application. Typically you can configure the SSLContext with the needed trust material supporting the certificates you need.
However, be aware that SSL in Java is one of the more annoying parts, because the smallest configuration error can give you some really strange error messages.
Previously I have had success implementing two-way SSL authentication (public or privately signed certs) using not-yet-commons-ssl, and although the library is a bit old, it is easier to use than raw Java, especially if you have to support multiple JVM versions.
You can use your own trust store and define it in JVM -D parameters for SSL.
That I always do in exact same corporate environment I have.
Related
I have a spring boot client application and a server application. I am implementing MTLS client authentication part. I have a client certificate that is self signed and this needs to be added to a custom truststore in the server. Basically I am looking for a mechanism to add my custom truststore at runtime.
I want the default truststore and the custom truststore to be picked up. I implemented this using TomcatServletWebServerFactory but I did not have any luck. Can someone please help. I am looking for a programmatic solution.
I do not want to change the default java truststore. I still need that.
Since you do not want to replace the existing truststore with your custom one (that could be done by running the JVM with a few system properties) you need to add code that trusts a peer if the builtin or a custom trusttore approve the client.
For this you need to create and install your own Trustmanager. See an example here: https://community.oracle.com/tech/developers/discussion/1535342/java-ssl-trustmanager
If the checkClientTrusted and checkServerTrusted methods do not raise an exception the certificate is approved. Leaving the methods empty would even turn off any certificate validation - not to be recommended.
In order to establish a SSL connection with client certificates between a Spring client application and a Spring server application, there are a few things to note:
Involved Trust Stores
There are two very different trust stores relevant in this context:
The trust store used by the client to determine whether it can trust the server's SSL certificate. When using the java.net package for client requests, the trust store is configured via the JVM property "javax.net.ssl.trustStore" - see e.g. https://docs.oracle.com/javadb/10.8.3.0/adminguide/cadminsslclient.html
The trust store used by Tomcat (the underlying servlet container used by Spring Boot in its default configuration) to determine whether it shall trust a client. This is configured via the spring application property "server.ssl.trust-store" - see https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.server.server.ssl.trust-store
In the context of a Spring server application the first one is relevant for connections which the server makes to a second server - so only when the server acts as client as well - e.g. when acting as a proxy server.
The second trust store is relevant for connections between the server and its clients. This is the one you need to deal with.
Certificates in the Tomcat Trust Store
The trust store which is used by Tomcat does NOT contain the client certificates. Instead, it must contain the certificate of the Certificate Authority who has signed the client certificate. So when using self-signed certificates, you need to install the CA certificate which you have generated on your own.
The big advantage of this is, that you do not need to change the server trust store, when you grant access to new clients.
The downside is, that you have to handle a certificate revocation. The CRL (certificate revocation list) is also stored in the trust store. See:
CRL Explained: What Is a Certificate Revocation List?
Merging the Default Trust Store and the Custom Trust Store
As now should be clear, this is not a good idea and would constitute a major security flaw, as it would allow any client which has a certificate signed by a CA in the default trust store (which can be easily obtained) to connect to the server. The server trust store must only contain those certificates which you use to sign your client certificates!
And there is no need to merge the two, as this are totally separate trust stores with totally different functions.
But, of course it is technically feasible to merge trust stores. This can all be done by keytool - see below.
Managing Trust Stores
Adding, deleting, exporting, listing, and printing certificates and CRLs can all be done via the Oracle command line tool "keytool", which is part of the OpenJDK. See
keytool Reference
Today we had production issue for which we had to install ssl certificates for an application. So I'm trying to update ssl certificates in my truststore which is already configured in jvm properties. But I've observed that without restart of jvm, I can see applications deployed on the jvm have picked up certificates. Is this kind of behaviour possible??
Is it possible to use openssl to generate the necessary certs to provide self signed certs for ibm MQ broker (version 9) and client. Or can i only use ibm's internal mechanism to generate the certs (ie. runmqckm -cert ).
Please advise.
B.
The queue manager requires a CMS format keystore that must be managed using IBM's tools. I recommend runmqakm instead of runmqckm to manage the queue manager's keystore since runmqakm is compiled C and you can run through an entire script of commands before runmqckm is done firing up its JRE.
For anything that can use a JKS, feel free to use OpenSSL, Keytool, or anything that works with x.509 certificates. This includes Broker's Java nodes, MQ File Transfer Edition agents, MQ client apps using native Java or JEE, and so on.
I am writing a Java proxy which communicates to other servers using SSL.
It all works well using ServerSocketFactory along with keystore and trustore which is populated with the server cert.
I wonder, is there a way in Java 7 to disable the certification and trust all servers? (and yes I know this is risky - bu the proxy is for internal use only)
I have seen some examples of implementing TrustManager using X509TrustManager implementation, although apparently Java 7 does not support these contracts and X509TrustManager itself has been deprecated.
Appreciate your advise and any code sample on Java 7 that works.
MITM proxy servers (i.e. servers capable of looking into SSL/TLS traffic) normally use their own CA to generate fake certificates for the requested site.
Install this CA certificate in your client's trust store instead of tweaking the code. This is a much cleaner solution, and in the long run, it's easier to deploy.
(For a more direct answer to your question, the countless example of trust managers that do nothing still work fine in Java 7.)
What I did was implementing a java.security.Provider using the code mentioned in this post
https://code.google.com/p/misc-utils/wiki/JavaHttpsUrl
Note: it is the second solution offered.
This post does not mention that you should also add a keystore in-order to make things work.
So, these VM argument should be set as well (Unless so you will get an error message of "no cipher suites in common"):
-Djavax.net.ssl.keyStore=KEYSTORE LOCATION
-Djavax.net.ssl.keyStorePassword=YOUR PASS
I hope this will help you, since in all the places I looked at this part was not mentioned.
See related question.
I have a PEM file provided to me and was told that it will be needed in establishing a SSL socket that connects to a c++ server for some API calls. Does anyone know how I can read in the PEM file and connect? I was also given the parapharse password.
It sounds like the PEM file is a client cert for you to use to login to the server. If it is the client cert, and it sounds like it is, you will likely need a ca cert file also to use in validating the servers certificate in order to establish a connection.
The CA certs need to go into a truststore and your client certs need to go into a keystore. In Java, both of these will be JKS (although it has limited support for PKCS12.) There are default keystore/truststore locations for the JRE as well as for each user. You can also specify external locations for these files in your code, as in the examples below. The commons-ssl library seems to be able to support PEM directly, without the need for JKS, but I haven't used it.
The default passphrase for these keystores in Java is "changeit" without the quotes.
This page shows you have to read the PEM into your keystore/truststore. Here is another example.
Once you have your truststore and keystore set up properly, you need to pass the following JSSE system properties to your JVM:
javax.net.ssl.keyStore
javax.net.ssl.keyStoreType
javax.net.ssl.keyStorePassword
javax.net.ssl.trustStore
javax.net.ssl.trustStoreType
javax.net.ssl.trustStorePassword
You may specify them as -D parameters to the JRE or, as in the examples below, programatically.
Once you finish that, heres a commons-ssl example of creating a socket. Also, heres the Java api for SSLSocket. Heres also an example that doesn't use any apache commons.
You need a library that handles SSL. As John Ellinwood noted, some frameworks (such as Java 2 SE) offers these built-in, for others you'd need to use 3rd party libraries.
C developers often use openssl directly, but it can't be said to be easy and when using C++ there are several "gotchas" that are easy to fall into.
I suggest you use a C++ network library with support for SSL, such as QT's network library, or Poco NetSSL. See here for some tutorial documentation and here for the API documentation - you probably want to take a look at initializeClient which takes a PEM file directly.