3

What is the use of mutual authentication in TLS without restricting the client cert?

Here is my understanding about client/mutual auth using TLS.

The idea is that both the server the client authenticate/verifies each other certs so,

1- The client verifies the server cert based on its CA trust store 
2- The server verifies the client cert based on its *CA trust store*

Now the key point to me is the second one, the server has to trust the client certificate by either saving it in the server trust store, or save the CA/ICA of the client cert, which should be private to the client, not via public CA, private CA to that client that the server wishes to trust.

Now [rfc5246][1] says the following

If the client has sent a certificate with signing ability, a digitally-signed
CertificateVerify message is sent to explicitly verify possession of
the private key in the certificate.

This won't achieve any authentication correct? for example, if I have a server that trusts any certificate signed by the trusted CAs around the world, then why bother at all with client authentication at all? [1]: https://www.rfc-editor.org/rfc/rfc5246

Community
  • 1
  • 1
ZKA
  • 97
  • 1
  • 7

1 Answers1

3

When the server gets the client cert (as part of the TLS protocol), the server does all the normal cert checks, including chaining up to a trusted root. For the server to trust a client cert issued by Foo CA, the server needs to have the Foo CA root already installed at the server.

The corner stone of X.509 certs is root CA certs. A host should only trust certs issued by the CAs it trusts. So when an admin installs FooCA's roots, the admin is stating "I trust the certs issued by Foo and I trust that Foo did appropriate checks that the cert is valid and assigned to the correct entity."

The server does not need to store the client's cert, there's no reason to. When the cert comes in as part of TLS, the server simply checks it. No persistence needed, and if anything fails, and that includes not having the Foo CA root cert installed, then the connection fails.

The server DOES authenticate the client. A certificate binds a public key (in the cert) to an entity; for example CN=frodo@theshire.com. When the client connects and the server asks for the client cert, the server will check that the name in the cert (frodo@theshire.com) matches the name of the user, but it will also get the client to encrypt some data using the private key associated with the public key in the cert, and if the server successfully decrypts the data, then the client (frodo@theshire.com) really is who they claim to be. Or, in the worst case, an imposter who got access to Frodo's private key :)

Does that help?

MichaelHoward-MSFT
  • 269
  • 1
  • 6
  • I helps a lot, I have a follow up question based on your last paragraph, can I install the chain of a CA in my server, that chain signs certs for the theshire.com and foo.com, but I need the server to accept TLS connections only from theshire.com, is that possible? or is it possible ONLY when the two clients are using two different CA/ICAs but the server only trusts/installs one of these CA/ICAs? does the question make sense? – ZKA Jun 05 '20 at 05:16
  • 1
    The way X.509 works, once you install the root CA cert (and any other certs in the chain) then you trust any leaf certs from that CA. So if Foo CA issues certs to frodo@theshire.com and to sauron@morder.com, then you trust them both. Now, assuming your code is doing the right stuff and has done all the correct crypto verification, now you can make whatever other decisions you want - including taking the name out of the cert and only allowing theshire.com. It's important you do all the crypto work first, however, such as the the chaining to a root. If you have any further q's lemme know. – MichaelHoward-MSFT Jun 05 '20 at 11:55
  • I see that load balancers always go with installing/trusting an ICA that issues client cert, usually the client creates this ICA in-house and issue cert for the client auth purposes only, why don't they do by the CN name? isn't that easier? or is there a security concern with checking the name approach? – ZKA Jun 05 '20 at 19:29
  • 1
    When chaining to the root CA cert, you should never JUST chain to the intermediate CA certs, you should always go to the top. Checking the name is fine, *so long* as you have done all the real crypto stuff first, most notably chaining to the root and checking the sig on the cert is valid. Of course, there's all the other stuff like date ranges, but that's done after the crypto stuff. – MichaelHoward-MSFT Jun 05 '20 at 21:15
  • Thank you, yes root included, I wanted to edit my question but it didn't allow me :), thank you so much for keep answering my follow up questions. – ZKA Jun 05 '20 at 21:17
  • you bet - any time :) – MichaelHoward-MSFT Jun 09 '20 at 14:02
  • This has been very helpful. Why do 99% of implementation guides usually fail to mention this part? :`The server DOES authenticate the client. A certificate binds a public key (in the cert) to an entity; for example CN=frodo@theshire.com` – RobOhRob Jan 08 '21 at 21:02