2

I'm tasked to implement a 2 way TLS in the context of Java. I found an example (https://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm) and was able to put it together as a demo myself. Just like this example, all the other examples I can find on-line are using self-signed certificate. But now the issue comes what if we use third-party CA signed certificate. How would it impact this demo? And also please consider these 2 scenarios:

  1. On server side, I only care if the client is certified by the CA. For example a totally new client that server was not aware of before, as long as it can obtain a certificate with the CA, then the server would provide the service;
  2. It's point-to-point relationship, not only the client needs to present a certificate issued by the CA, the server would also check the certificate to see if the client is on a predefined list of entities to be eligible for the service;

So how should I configure my keystore and truststore respectively for these above 2 different scenarios?

fangtasticmr Z
  • 33
  • 6
  • Possible duplicate of [Java HTTPS client certificate authentication](https://stackoverflow.com/questions/1666052/java-https-client-certificate-authentication) – Am_I_Helpful Jul 11 '18 at 23:24

2 Answers2

3

The difference with CA-signed certificates at both ends is that unless the CA is unknown to the JRE's built-in truststore, you don't need to do any exporting from keystores and importing into truststores, and you don't need your own custom truststores. You just need to import the CA's bundle and the CA-signed certificate resulting from your own CSR into your own keystore in each case.

the server would also check the certificate to see if the client is on a predefined list of entities to be eligible for the service.

That's an authorization step that the server application must perform after the connection is completed, as you said in your question. It isn't part of the keystore/truststore setup, which is only to do with authentication. Don't mix these steps up. The server (or an Apache HTTPD in front of it) would check the subject DN of the certificate to see if that DN has the appropriate role(s) to use the requested service (e.g. URL). This can be built into Apache HTTPD, or Tomcat CMA.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks and then under the circumstance I described, would it be fair to say it would be better for me to use self-signed cert rather than CA signed. Because I don't need to do the extra "Authorization" step, and the trading partners and myself don't need to spend the money to purchase the cert from the 3rd-party CA. – fangtasticmr Z Jul 12 '18 at 15:31
  • 1
    I don't think it is ever better to use self-signed certificates. They present a lot of headache in that there are extra steps required both at the owner of the self-signed cert and at every peer. You *do* need to do the extra authorization step, and that is the essence of my answer. – user207421 Jul 13 '18 at 04:17
1

On either side, client and server, you are going to need the keystore for that side. That only really needs the certificate and private key.

Then, each side needs the trust root of the other side, but doesn't need its own. The server needs the root CA of the client, and vice-versa (unless you ignore server-certificate verification on the client). The root will be in the truststore.

Then on top of that, each side needs any intermediate CAs of the other side. They can either already have them in their truststore, or, they can receive them from the other side.

So to be polite, each side could also include their own intermediate CA certificates and send them in the chain to help the other side out. Otherwise, neither side actually has any need for their own CA or intermediate CA certificates.

So the server needs the client's root CA, and will either need any intermediate CA certificates ahead of time, or receive them from the client.

UPDATE: Responding to your comment below, if you want to filter client certificates, it is possible in some TLS implementations (openssl, for example). You can hook into the verification step and have your say as to whether or not the connection is allowed. This seems a little low-level, but it does have some advantages. For example, you could keep a concatenation of all permitted client certificates in a text file (only the public certs -- not any private keys), and read this into an openssl "stack of certificates" at start up, then run through that looking for a match on each TLS connection. That is a very specific whitelisting of clients.

I would caution against simply checking the DN for a pattern to decide if the client is allowed, as this could be a big security hole. An attacker could simply obtain a public certificate from any well-known CA, asking for a DN that fits the pattern you are looking for. This would be accepted by your server because the CA is one of hundreds of trusted CAs on the typical default truststore. Once the connection is accepted, the DN fits the expected pattern, and so the client is allowed.

Jim Flood
  • 8,144
  • 3
  • 36
  • 48
  • well, seems you are only describing the general mechanism of 2 way TLS. What I'm really asking is the differences between using self-signed certificate and third Party CA signed certificate, and specifically in the context of setting up keystore and truststore. – fangtasticmr Z Jul 11 '18 at 23:34
  • 1
    Oh, I see. I think @EJP has your answer then. Out of the box, you already have a truststore on the machine on most platforms, with hundreds of pre-installed trust roots. So the server may not need anything from the client at all. – Jim Flood Jul 12 '18 at 02:24
  • Sure, @EJP answered part of my question. Furthermore, what if the server only provides service to certain client A. Say, CA certifies client A, B and C. And all of them request the server for service. Server recognizes the CA issued certificates presented by all clients. But once the Server reads in the content of the certificate, it only provides service to A but not B and C. Because this service is only setup for A. So how do you setup the keystore and truststore on both sides for this scenario? – fangtasticmr Z Jul 12 '18 at 05:29