Requirement for CA private key to use a CRL
-
Hi,
I've recently moved an openVPN server running on a linux server to pfSense 2.0-RC1. I was able to successfully import my existing pki certificates via the cert manager and things are running fine. The only thing that perplexed me a bit was the requirement to import my CA's private key in order to utilize the existing CRL.
For my edification, would someone please explain why the CA private key is required? I understand the need if one wishes to utilize the cert manager to generate server/client/crl certificates, but if importing existing certificates I would think that the gui would allow a crl to be imported on the 'Certificate Revocation' tab of the cert manager (in my case, there was no 'add' button until I imported the CA's private key). Thanks very much…
-
I don't really know your knowledge in relation to PKI theory. So apologies if you already know this.
All CRL responses are returned as numbers, these numbers correspond to a set of known statuses and are signed with a private key to ensure that spoofing cannot occur. E.g. if you had a man in the middle attack where DNS were compromised and a false revocation server were accessed, the response signature is verified by the public key of the CA certificate (available to the client.)
The signatures could be stored pre-signed by the certificate server. This is sometimes done as it places an unnecessary burden on the server to re-sign every time (I don't know if this is true with pfsense - I am a windows guy). It makes no sense to have a certificate list for a specific certificate authority which cannot be added to (because further values cannot be signed.) or if they are signed every time then it makes no sense to have a CRL list which cannot be deployed to the client.
-
The signatures could be stored pre-signed by the certificate server. This is sometimes done as it places an unnecessary burden on the server to re-sign every time (I don't know if this is true with pfsense - I am a windows guy). It makes no sense to have a certificate list for a specific certificate authority which cannot be added to (because further values cannot be signed.) or if they are signed every time then it makes no sense to have a CRL list which cannot be deployed to the client.
I appreciate the input, but perhaps I wasn't clear. By way of example, I have setup a private certificate authority …the self-signed root certificate and any generated server/client certificates are managed off the network on a stand-alone workstation. I maintain a crl, I can add to it, and I have a means to distribute the crl and other certs as appropriate. I do not need nor wish to utilize pfSense for this purpose. I do wish to utilize these existing certificates with OpenVPN on pfSense however, including the crl.
In this particular small example, I do not wish to create an intermediate CA. There has never been a need to distribute the CA's private key with past freeRadius and OpenVPN server deployments, and as a general practice, I would like to keep it under 'lock and key'. I can easily enough circumvent the need to import the CA private key with pfSense ...it's just a matter of creating the crl using the 'Edit File' menu item and adding the crl-verify directive to the OpenVPN configuration via the gui....but my preference would be to just have the ability to import it as is the case with any other certificate.
I don't claim to be an expert in this arena, so any constructive feedback would certainly be welcome. Thanks...
-
It shouldn't have been restricted in that way. When I wrote the CRL manager I apparently just skipped that particular scenario.
Should be in new snapshots:
-
It shouldn't have been restricted in that way. When I wrote the CRL manager I apparently just skipped that particular scenario.
Should be in new snapshots:
Thanks very much for this Jim…
-
Glad i found this thread, Just updated and i can confirm that the latest snapshot works well with the CRL list. Thanks
-
I too am glad to have found this thread. I have the same problem and will try the latest version of the firmware later today. Thanks Jimp!
