Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Requirement for CA private key to use a CRL

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 5 Posters 4.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      Slab
      last edited by

      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…

      1 Reply Last reply Reply Quote 0
      • C
        chris27uk
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • S
          Slab
          last edited by

          @chris27uk:

          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...

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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:

            https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/44bcc1bedceb947c58623b85dcc83b2bc578f79d

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • S
              Slab
              last edited by

              @jimp:

              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:

              https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/44bcc1bedceb947c58623b85dcc83b2bc578f79d

              Thanks very much for this Jim…

              1 Reply Last reply Reply Quote 0
              • R
                Ryanmt
                last edited by

                Glad i found this thread, Just updated and i can confirm that the latest snapshot works well with the CRL list. Thanks

                1 Reply Last reply Reply Quote 0
                • C
                  cyboc
                  last edited by

                  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!

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.