2路TLS和CA签名证书

Question

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?

Answer 1

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 (eg URL). This can be built into Apache HTTPD, or Tomcat CMA.

Answer 2

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.