What must be contained in the keystores/truststores for mutual authentication?

Question

I am trying to perform mutual authentication in Java. The structure of what I am trying to achieve is: server with self-signed certificate acts as a CA, signing the client certificate. Therefore, this is what I keep in each keystore/truststore:

Client:

Keystore:

Client's SSL keypair.
Signed certificate by server (related to the keypair).

Truststore:

Server's selfsigned certificate.

Server

Keystore:

Server's SSL keypair.
Self-signed certificate (related to the keypair).

Truststore:

Server's selfsigned certificate.

I am able to perform server's authentication, but when I enable setNeedClientAuth(true) on the server, I get the following errors at the log: http://pastebin.com/raw.php?i=P52Qq89z So the server seems to authenticate but the client cannot provide the CA chain, may it be an issue with the contents of its keystore?

I used openSSL to generate the keys and the certificates, KeyStore Explorer to create the keystores (after a couple of days of unsuccessful use of keytool) and JDK 1.7.0_51

UPDATE: the problem was solved following these instructions: https://stackoverflow.com/a/12150604/2891462 It was a problem with how the CA self-signed certificate had been created (only an issue in JDK 1.7, apparently).

Self-signed certificates are mainly useful when used on their own. If you're planning to use it as a CA certificate too, you might as well separate the CA certificate and the server certificate. It will certainly be useful in the long run. — Bruno, May 08 '14 at 17:13

score 4 · Answer 1 · answered May 08 '14 at 16:33

4

for mutual authentication(2 way SSL) only 2 things needs to be done

server's certificate exported from server's keystore(not trust store - in case you are using different trust and key store)

and second is

client's certificate should be present in server's truststore(not key store - in case you are using different trust and key store)

additionally there is a good blog here to read about the same

answered May 08 '14 at 16:33

dev2d

4,245
3
31
54

Thank you. I can get it working if I specifically add the client's certificate to the server's truststore. However, I would like to not need to add the certificates of all clients, but saying "If the certificate provided by the client is signed by me, accept it". So my problem is the client not being able to provide the certificate chain apparently, right? – user2891462 May 08 '14 at 16:36
I just found something interesting: http://stackoverflow.com/questions/11153058/java7-refusing-to-trust-certificate-in-trust-store I'll try it later and comment on it. – user2891462 May 08 '14 at 17:12
Yes, that was the problem: I regenerated the CA .crt, updated the client's keystore and server's truststore and it works! – user2891462 May 08 '14 at 17:23

score 3 · Accepted Answer · edited Oct 07 '21 at 06:01

There a couple of things that are wrong in your configuration.

Looking at your debugging logs, your certificate doesn't have the basic constraints to say CA=true.

[
  Version: V1
  Subject: CN=Ficticious bank, OU=SoE, O=University, L=London, ST=England, C=UK
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  Key:  Sun RSA public key, 2048 bits
  Validity: [From: Wed May 07 19:21:23 BST 2014,
               To: Thu May 07 19:21:23 BST 2015]
  Issuer: CN=Ficticious bank, OU=SoE, O=University, L=London, ST=England, C=UK
  SerialNumber: [    9a7143cf f5ecfbf8]

]
  Algorithm: [SHA1withRSA]
  ...
]

It's not going to work as a CA if it's not a CA certificate. See RFC 3280 (and 5280):

   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Secondly, this certificate, which you also want to use as an End-Entity Certificate (EEC) for your server doesn't have a valid name for that server: no Subject Alternative Name and a CN that visibly doesn't match any host name. While the default SSLSocket doesn't do any hostname verification by default (you can configure it), it's useful to have a valid host name for a server certificate, since clients should really verify it in principle.

Overall, there doesn't seem to be many benefits in using the very same certificate for the CA and the server certificate. Self-signed certificates are mainly useful when used on their own. If you're planning to use it as a CA certificate too, you might as well separate the CA certificate and the server certificate. It will certainly be useful in the long run, in particular when you have to change the server cert, on "Thu May 07 19:21:23 BST 2015" in your example, or if perhaps you need to re-issue the server cert for any other reason.

Beside this, you have the right idea for your keystore and truststore:

Client:
- Keystore:
  - Client private key and certificate chain in the same entry (but the CA certificate itself can be omitted).
- Truststore:
  - CA certificate(s) that can validate the server cert.
Server
- Keystore:
  - Server private key and certificate chain in the same entry (but the CA certificate itself can be omitted).
- Truststore:
  - CA certificate(s) that can validate the client certs.

Thank you very much. Indeed, there was a problem on how the self-signed certificate was generated, I updated the original post. I will change the structure so that the server's certificate is also signed by an independent CA, and research on the CN hostname verification. — user2891462, May 08 '14 at 17:29
You might find [XCA](http://sourceforge.net/projects/xca/) quite useful, if you're not quite sure about the `keytool` options. Remember you can use a PFX/P12 file directly in Java by choosing the `PKCS12` keystore type. — Bruno, May 08 '14 at 17:31
Regarding host name verification, you might be interested in [this](http://stackoverflow.com/a/8444863/372643) and [this](http://stackoverflow.com/a/17979954/372643). — Bruno, May 08 '14 at 17:33

What must be contained in the keystores/truststores for mutual authentication?

2 Answers2

Linked