2

I am new to SSL and Certificates . I have been doing my research about client certificate authentication. I have read this and wiki.

So If I have to implement a client certificate auth solution for my B2B REST service should I do following

  1. Ask clients to generate their own private-public key and generate certificate (CA issued?) for their public key. Send that certificate over email or USB key.
  2. On the server side import client's public certificate into trust store and enable client authentication
  3. During the hand shake client presents it's certificate and gets authenticated, because server has a copy of cert in it's trust store and can verify CertificateVerify message

My question is how does it stop anybody to pose as my client. Let's say a hacker X sends a CA issued certified to the server as part of handshake. Then server would automatically trust it and grant access.

Community
  • 1
  • 1
Sridhar Chidurala
  • 546
  • 4
  • 15
  • Here is the practical working solution for User web authentication using his digital signature on usb token or smart card... https://stackoverflow.com/a/55757349/9659885 – Bharat Vasant Aug 27 '19 at 05:27

2 Answers2

3

Client Cert based authentication doesn't actually verifies if the client connecting is in your whitelist.

Lets say client X gets a cert from public CA Y, and you import Y's cert in your trusted list, then the connection from X will succeed.

Now, if a intruder Z buys a cert from same CA Y (knowing what CA your application would trust is a complex part), and tries to authenticate with your application, the verification would still succeed, because its a valid cert from a trusted CA. The application would continue to serve contents to Z, which you dont want.

So the best approach is to self sign client clients cert(and deploy it on clients you trust) and you will be the CA in this case, which limits the intruder from gaining access.

Here is some reference, 

# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr

# Sign the client certificate with our CA cert.
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

If you just want to allow only a few known IP addresses, then a network based IP blocking/Throttling is the preferred approach( but, has its own complexity of managing/updating IP list).

David
  • 887
  • 8
  • 7
  • Take Cloudflare as an example: I can get the public cert they send from here: https://support.cloudflare.com/hc/en-us/articles/204899617-Authenticated-Origin-Pulls. All I need to do is to find out the CA and make a certificate from there with the cert included. Then I can authenticate from my local computer? – mslot Jul 08 '20 at 16:32
  • 2
    I've looked up nearly a hundred articles on this subject and they all seem to lack this crucial part `if a intruder Z buys a cert from same CA Y (knowing what CA your application would trust is a complex part), and tries to authenticate with your application, the verification would still succeed,` – RobOhRob Jan 08 '21 at 20:44
  • @RobOhRob you dont buy it from any external CA, the point about client cert auth is, the server acts as a CA and sign the cert. – David Mar 18 '21 at 19:57
2

I've to break down your question into two parts.

Part one: Let's say a hacker X sends a CA issued certified to the server as part of handshake. Then server would automatically trust it and grant access.

If X aquires the client certificate of an authentic client then that's ok. Because the certificate itself does not contain any secret. Those certificate can be published anywhere without doing any damage (Except if you want to keep your email address a secret, try not to publish it. But it may will get out there after some time. And company crafted X509CertificateExtensions are not considered as well.).

The private key is the important key which must be kept secret by your client. If X gets the private key as well, X can impose an authentic client and login into your system. Therefore clients must protect those private keys from getting stolen!

That's because within the client-auth handshake, the server not only requests the client certificate. The client must also prove that he's the real owner of the certificate, by using his private key as stated in the wiki you referenced: The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. Such a signature can only be done if the client posesses the private key belonging to the certificate, as stated in the wiki as well: This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.!

Part two: How do establish a initial trust relationship?

That part is difficult if there are many clients involved. That's why the PKI was established. You trust the CA, and the CA should to the identity check on that clients who request a certificate.

For homebrew solutions in which case you have your own CA, or you don't trust a CA, the part is up to you. You must be sure that you grand access to your services only to authentic clients. If you do this via USB keys and the clients hand them over to you in person, that's ok.

If you receive an email which says "hello, i'm your friend XYZ from ABC, remember? Btw. here's my certificate" - check it twice.

Manuel
  • 3,828
  • 6
  • 33
  • 48