1

I have a private application - that has one server and many clients and I want to use two way authentication(AKA client auth) I use Tomcat server and java keytool to create TLS certificates.

If I create one certificate authority, and create on certificate (signed by the CA) for the server, and pre-install it for all clients - then they can authenticate server (although I didn't really had to sign it with the CA, but anyway)/

If I create a client certificate, sign it with the CA, and then install it on the client:

  1. Does the server need to hold the client certificate(and the CA) or just the CA in the truststore? And by that I mean - Is there any place that I need to "Remember" the client certificate and check against an existing file(that will of course - match one to one with the certificate the client sent)

  2. Or is it enough to just check the signature of the CA on the certificate, causing that just one copy of the client certificate exists in my system, and cryptographically - it is secured to assume that if the signature of the CA exists(and validates) on the certificate a client sent me - it is the client

Improve this question
1
  • Case 2 is true as far as I can tell. You can verify that the keypair / cert if the user was signed by you, and you ought to be careful with what you sign. If you are careful with signing, and if you handle revocations as necessary, then you're fine. However, it is recommended for administrative purposes to track what certs you have signed. Case 1 is equally possible, but inefficient to implement.
    – Natanael
    May 4, 2015 at 23:23

1 Answer 1

Reset to default
0

Your Option 2 is sufficient and cryptographically secure. If the CA's signature on the client's certificate validates (and the CA's signing keypair hasn't been revoked due to compromise) then yes, you can assume that the certificate is authentic - ie it was issued by your CA and hasn't been tampered with. Remember that a signature is an encrypted hash of the whole certificate, so if even a single character has been changed, then the signature will fail to validate.

However, that does not tell you anything about who sent it to you. Certificates are public, everyone could have a copy of everyone else's, so Alice could send you Bob's certificate and claim to be Bob. In order to authenticate the client, they need to prove that they have the corresponding private key. Remember that certificates only contain public keys, the matching private keys are never made into certificates, and are stored separately. This can be done by having the client send a piece of data that they signed along with the certificate.

About your Option 1: in a full public-key infrastructure in which the end-users can encrypt for each other and verify each other's signatures, everybody needs access to everybody else's public-key certificates. This is usually done by having the CA keep a copy of everybody's certificates and display them in a public place like on an HTTP site, or in a public LDAP directory.

Improve this answer
3
  • I agree that when a CA signs its own certificate (aka "self-signed") it's a little weird, but that's how the system works, oh well.
    – Mike Ounsworth
    May 5, 2015 at 0:31
  • If I use tomcat connector attribute clientAuth="true" ,using Option 2, will it authenticate the client or just check the certificate that was sent against the CA ?
    – Yoav R.
    May 5, 2015 at 7:51
  • No idea, I've never used tomcat, sorry...
    – Mike Ounsworth
    May 5, 2015 at 11:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .