Should the client have the same keystore as the server?

问题

I am reading about the best way to create a secure connection between a client and a server.

Through this tutorial it seems that the certificate (and the keystore) is not only given to the server, but it is also given to the client.

Isn't this insecure? If the client has the certificate file (in the keystore), won't it have all the server private keys?

In the end what I want is to have a secure/encrypted connection between the client and the server, while the client itself proving to the server that it is an authentic client. Is this the right way to go?

Thanks!

回答1:

As Boris stated in the first comment, the keystore contains the keys to authenticate and truststore contains the certificates that are trusted, as their names imply.

First of all, a certificate does not have to contain the private key. It is just an identity with a public key (with possibly signed by a trusted party, like CAs). That's why, if you use them appropriately, it is not insecure. What is the appropriate way of this? Here we go:

Before answering your question, i.e. the case that not only the server but also the client is authenticated, let's consider the usual case: only the server is authenticated by the client. In this scenario, we have three parties: Certificate Authority (CA), Server (S) and Client(C). To make it work, you should do the following:

1. Create a keypair for CA and store it in some ca.jks.
2. Export the certificate (containing only the public key, not private) from ca.jks and import it into another jks file, namely truststore.jks.
3. Create another keypair for S and store it in some server.jks.
4. Sign the certificate of S with the private key of CA. For this procedure, you need to generate a CSR (certificate signing request) from server.jks, sign the csr file with ca.jks and produce some crt (or pem, whatever you want) file containing the signed certificate. Finally you have to import this crt file back to server.jks. It is important to use the same alias as before.
5. Use server.jks at S as the keystore, and truststore.jks at C as truststore.
6. Keep ca.jks in a safe place. It is the root of trust.

In this way, C trusts CA since its certificate is in his truststore. Since S has a certificate signed by CA, C will trust S too. In other words, S is authenticated by C.

To achieve what you want, i.e. both parties are authenticated by each other, you will have two certificate authorities, namely CA1 and CA2. (They can be same of course, but I am writing like this for the sake of completeness.) You have to do the procedures above twice: once with CA=CA1 and once with CA=CA2. The first one is exactly like above. In the second one, you will create client.jks, sign it with CA2, and use public key of CA2 as the truststore of the S. (Just the roles of C and S are swapped.) In this way, both parties will authenticate each other.

As I said, you can use the same CA, which is very convenient and reasonable.

I know this is a long answer but be sure that I omitted most details and tried to make it simple. I hope it helps.

EDIT: Again, do not get confused: the client authenticates himself using his private key, stored in his keystore. Certificate is already a public thing...

Regarging your question, of course, if some thief steals the keystore file, then he can imitate himself to be the real client. The server cannot know who he is communicating with, he only validates the certificate. For such scenarios, issued certificates can be revoked. Search for revocation on the web. Simply, if you know that a client's keystore is stolen, you will inform the server about this through revocation, instead of regenerating all key material.

One corner case for this is, certificates are some kind of bindings of public keys with identities. For web servers, which is the usual case, their certificate binds their public key with their hostname, i.e. hostname is their identity. So if abc.com uses the certificate issued for xyz.com, your browser will give an error when you try to connect to abc.com. In Java world, this is called host name verification. The common name field of certificates are used for such identities. (When you generate using openssl or keystore, it may ask you a common name, and it is very important.) If your clients are actually servers with static IPs or some valid domain names, you can use it. In this way, since the thief will try to connect from some other IP or domain, the server will detect it through hostname verification. However, usually clients do not have such stable identities, thus it is very hard to use this technique, so the thief may be able to imitate the real client.

来源：https://stackoverflow.com/questions/41983525/should-the-client-have-the-same-keystore-as-the-server