Accessing pfSense-based CRL remotely

I have an OpenVPN instance operating on a pfSense firewall virtual machine. Within OpenVPN I’m using both radius-based two factor for authentication, and certificate-based auth in the client. Doing this of course requires setting up a certificate authority somewhere, and for convenience I’m doing this with the built-in CA feature of pfSense.

Fast forward to having a different need where client certificate auth through an apache or nginx reverse proxy would be convenient. Well we already have these certs for all the users issued by the pfSense server for OpenVPN use, and we already have a CRL built into the pfSense server tracking which certificates have been revoked, and we already have the certificates set to expire at reasonable intervals. Sure would be nice to use the same certs, but how to get this secondary system to know if the certs have been revoked?

  1. SSH into your pfSense server and switch to root (sudo su – root)
  2. cd to /var/etc/openvpn/ and figure out what OpenVPN instances you have. If you only have one, then all you have to worry about is the server1 directory. It seems like server ID’s you find will be one number higher than what’s shown in the web GUI. For example, on my server I have both a TCP-based and UDP-based OpenVPN server instance, which if I hover over in the web GUI, shows id=0 and id=1, but on the filesystem I have server1 and server2.
  3. Assuming both, or all, of your OpenVPN instances use the same certificate authority, then you’ll actually find the same files in all of your instances under /var/etc/openvpn/server#/ca/, but if that is not the case, you’ll have to be sure you’re working with the one you intend to be.
  4. What you’ll find in the /var/etc/openvpn/server#/ca/ directory is both your CA certificate and your CRL, where the CA cert will typically end in .0 and the CRL will end in .r0. The file name will differ from one system to the next as it’s a subject name has of the actual certificate. You’d generate this name via:
openssl x509 -hash -noout -in filename.pem
  1. So now that you’ve found your CRL file, you need to get it into the web content directory the pfSense web server listens on; i.e. your management IP. And of course the system needing access to the CRL needs to be able to get to that IP. Easiest way to do this is via a cron job, and you can install the cron package via the pfSense Package Manager to have a web interface to it.

    Once that’s in place, the command you’d use is:
cp /var/etc/openvpn/server1/ca/FILENAME.r0 /usr/local/www/
  1. The above will of course differ based on your OpenVPN instance and the filename. I do not know where the CRL lives if you’re not using OpenVPN and are just using pfSense certificate management. If someone can tell me, I’m happy to update this article.
  2. There is of course a caveat to the above. Unfortunately, as certificates are revoked, the .r0 file is not regenerated, additional .r1, .r2, etc files are generated with the updated CRL, until such time that the OpenVPN server is restarted, or the system restarted. This means the .r0 may not be current, so your daily cron job that copies the file may be copying an out of date CRL if OpenVPN has not restarted. This is why I’d prefer to know where the real CRL lives, but haven’t figured that out yet.

    So, for the time being, I have a second cron job that restarts OpenVPN daily in my case, but this will boot your clients off, so use an interval and time of day that makes sense for your organization. Otherwise, if you can’t restart it whatsoever, you’ll need a more elaborate script to do the CRL updating based on the then-current iteration.

    Restarting OpenVPN can be done as follows; just adjust the numeric instance to the one you need:
/usr/local/sbin/pfSsh.php playback svc restart openvpn server 1
  1. Now that your CRL is in the right place, and with the correct contents, you just need to pull it from your other system at your pfSense management URL and/or IP, i.e.:
curl https://pfsense.management.url/FILENAME.r0

Leave a Reply

Your email address will not be published.