Best practice to store client certificates?

Question

I am building an app that requires mutual authentication. So I will enable my users to upload a bunch of client certs and when they make calls, they can use either of them. I will match the client cert from the incoming request to see if it matches any of the ones already stored, and if it does, the request will be honored.

Now I'm trying to figure what's the best way to store these client certs. I was thinking I could store them in a DB, or some kind of file/blob store, or I've learned they can also be installed in the store in the machine?

Which one of these options is ideal or considered as best practice?

What is the best practice to store client certificates?

Edit: My server is actually running a service on a Windows machine with IIS that other users will use.

Cutwater

Certificates are public information. They can be published like a phone number in a phone book. There's not really a best practice for handling them. On occasion, you will see some issues related to privacy, such as a server leaking info on its users based on public info like certificates and log files. But that does not appear to apply here. The matching private key (or a PKCS 12 file) is a different story. – Elysian

There is nothing secure about just having a client's certificate, and there is no particular reason to do so. What you need to verify is whether the owner of a certificate is authorized to use your server. You don't need certificates for that, just a table of subjectDNs. Having the actual certificate also causes problems when it comes time for the client to renew. – Scouring

Answer 1

1.) To answer your actual question:

You can store the X.509 certificates anywhere you want, lets call the location a truststore. If it is in your file system, a database or somewhere else. The X.509 certificates can be made public to anyone, the do not contain any sensitive information. Only the public key of the public/private keypair is stored in the X.509 certificate.

You just have to make sure that NO ONE ELSE is able to add/remove/modify certificates into your truststore. Otherwise the malicious person will be able to add e.g., his X.509 certificate into your truststore and you would trust him right away.

2.) Regarding your remark

I will match the client cert from the incoming request to see if it matches any of the ones already stored, and if it does, the request will be honored. 

A simple comparison of certificates is not enough. Anyone can send you any certificate. The fact that someone sends you a certificate is no proof that the person is the owner of the private key, corresponding to that certificate.

In order to be sure, the person who sends you the request (your incoming request) needs to generate a signature over e.g., the incoming request. If you receive the incoming request together with the signature, you can use the X.509 certificate to check if the signature is valid or not. There are lots of signature schemes out there, you need to figure our which you want to use (some are simple, some are more complicated).

Impudent