Is there any mechanism to audit which signed certificates are unrevoked?

Question

We are currently using EasyRSA and OpenSSL to manage our user VPN certificates for OpenVPN. The process we have in place currently is:

1. User generates a CSR on their laptop and sends it to us to sign
2. We copy the CSR to the server, sign it, and return the signed CRT to the user
3. We usually leave a copy of of the CSR and CRT on the server
4. When a user's cert is revoked, we store this information in a CRL

I'm tasked with auditing who has access to the VPN. As far as I can tell, the only way we can check who has access is by listing all of the CRTs on the server, and subtracting the revoked CRTs as listed in the CRL. However, this strikes me as not at all sound, as if anyone deleted a CRT and CSR from the server, we would have no way of knowing that it had ever been signed.

Is the current method trustworthy? If not, is there any way to know exactly which certs that were signed are still valid?

Answer 1

Certificates are for authentication, not for authorization.

Authentication is (here) about the OpenVPN server making sure that the alleged client is who they claim to be. This is the point of certificates: the client shows his certificate, which contains his public key and identity; the server validates the certificate (with regards to its trusted CA) to make sure that the certificate contents are genuine; the client demonstrates mastery of the corresponding private key (normally by generating a signature based on a challenge from the server -- this is done within the particulars of the communication protocol). That way, the server learns that whoever is at the other end of the line really is the owner of the public key which is in the client certificate; and the certificate, being verified to be genuine, allows the server to infer that the identity in the certificate really is that of the key owner.

Authorization occurs as a second step. Now that the server knows who is calling, it must still decide whether that client shall be granted access or not. This is a server-side decision.

From your description, you (apparently) configured OpenVPN to use certificates for authorization; or, said otherwise, you apply "automatic authorization" which grants access to anybody who could get authenticated. This is the root of your problem; certificates are not good for authorization. As you noticed, if you use such an authorization rule, then the "allowed users" cannot be reliably listed, unless you keep knowledge of all issued certificates. Also, if you want to close the access for a user, then you normally need to close it now, not within one week; but revocation is asynchronous and will be really effective only when the previous CRL has expired.

While a good CA must retain precise knowledge of all the certificates it has issued (if only to be able to revoke a certificate at will), there is no mechanism in X.509 to ensure the consistency and integrity of such a list. Moreover, the asynchronous nature of revocation is further proof that certificates provide inadequate means of authorization.

What you really need is to maintain an exhaustive list of "allowed users" on the server side (in the OpenVPN configuration files). The users would be identified by their name (apparently, OpenVPN uses the 'Common Name' part of the subjectDN in certificates to reference users); the server will extract the client identity from the incoming client certificates and authorize the user only if it appears in the list of allowed users. If you deploy such explicit authorization, then you have your reliable list of allowed user since, by definition, it is the list that the OpenVPN server uses to grant or deny access. Moreover, it allows you to block and unblock access for any specific user instantly.

Answer 2

Certificate Authority (host)

Shortly, in addition to excellent answer from Thomas Pornin

Your second step seem wrong:

You have to create a separated host with dedicated account, (idealy not root and using strong mechanisms to ensure root user don't have access to secrets datas like ca's private key.) and not connected to the Internet! Then care about data exchanges with this host!

CSR signature mechanism have to be used from and to this Certificate authority.

Care about backups too: Keep them encrypted and safe!