Using OpenSSL and pfSense to sign a Subordinate Windows Enterprise Certificate Authority

Disclaimer: A Root CA trusted by Active Directory should not be trivialized. Make sure you know what you are doing when working with PKI. Take the time to study the technology before implementing it in production environments. There hasn’t been any extensive testing of this setup, so your mileage may vary.

I have a pfSense Security Gateway Appliance that I use heavily in my home network. One of the features that I have taken advantage of is the ability to create a Certificate Authority (CA) and issue certificates.

I was recently in a SANS class taught by Jason Fossen and on the third day, “Smart Tokens and Public Key Infrastructure (PKI)”, we created a Windows Enterprise Certificate Authority. Naturally, I thought for fun I could implement this in my lab, but I wanted to make it a subordinate CA and have it signed by my pfSense Root CA. Unfortunately, as of this writing the pfSense Web UI does not support Certificate Signing Requests (CSR) from a Certificate Authority. It only has support for users and servers, which are the more frequently used options to be fair.

The solution is to securely export the pfSense Root CA Certificate and Private Key then upload both files with the CSR to pfSense using [Diagnostics->Command Prompt->Upload File], then use OpenSSL to sign the CSR created by the Windows Server. There are plenty of guides that show how to setup a Subordinate Enterprise CA and I will defer to them.

Note: pfSense stores the CA data in the config.xml file so we need to extract it via export and then save it locally.

Once you have those conditions above, ssh into the pfSense device and perform the following tasks:

Open openssl.cnf with a command line editor, then paste the config below. Remember to modify the CRL Distribution Point (CDP), Authority Information Access (AIA) and any other pertinent values for your setup.

The command to run after everything is setup:

The output will be a crt and pem that will need to be uploaded to your Certificate Revocation Server and accessible by the Certificate Services before you install the CA certificate. If you do not properly setup a CRL Server and place the derived crt and pem files properly, you will get an error when installing the CA on the server.

The Common Name (CN) must match what was configured in the CSR or you will get a different error.

The Country and Common Name can be configured from the command line by passing the -subj option:

If you forgot what the CN value is you can use openssl to view the value:

If you did everything correctly you can upload and install your newly signed subordinate CA certificate (.crt) to your Windows Server.

Note: Windows keeps the private key on the server so you only deal with the CSR.

Thanks for reading.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: