A Homelab Does Not Need Internal Public Key Infrastructure But I Did It Anyway

I am running a lot of services within my house, from what is on my Kubernetes to many other VMs hosting webapps, I wanted the ensure that from service to service they were using https for security even though its within the network.

There were a couple of ways to solve this issue and the reasoning why I did not go with them. You could use letsencrypt to add TLS certs onto everything. Or you could deploy your own private PKI infrastructure.

Letsencrypt

I use Letsencrypt for many other applications I use and for all my public facing applications I use Letsencrypt. It is amazing for what it does and it comes at a great cost... Free. In order to deploy certs you must install certbot which is Letsencrypt software to validate and provision certificates.

Certbot allows you to validate domain ownership in a couple of ways. Web challenge will spin up a temporary web server on port 80 that will host a validation key. With this you must have port 80 open to the server, and you have to have an A record pointing to your server. You can also only use a standard ssl certificate so only one domain.

Certbot does have a solution to the above challenges, you can make a DNS challenge so instead of querying a server for a challenge code it can look up a TXT record. They have two options for provisioning this record, either manually entering it into your DNS provider, or you could use a Certbot plugin to use APIs / other protocols to automatically add records into your domain. With DNS challenge you can request both wildcard certs or standard certs.

There are a couple of drawbacks to Letsencrypt. Its great for public facing applications which is where you will find it in my tech stack (For instance this blog site). However you cannot add any subject alternative names to your certificates. You might access your application with a variety of domains/hostname/ip address. With Letsencrypt you can only have a subject name no alternative names. The other downside is that its too easy I wanted to learn how PKI works and you cannot learn when its easy.

Private PKI

Private PKI is more complicated to set up than Letsencrypt, and what I have found out is if you set up something incorrectly you might have to re-set up your PKI such as key length. Though the main benefit is you learn in depth how our Public key infrastructure is set up.

I also already have two domain controllers in my lab (albeit they are not doing much) so I have the ability to automatically provision certificates on my client machines. This will make it easy if I decide to further extend my PKI into certificate based authentication though that is out of scope for now.

Windows Server

I decided to use Windows ADCS (Active Directory Certificate Services). One of the main reasons I decided to go with ADCS is its ability to automatically provision certs, and hand out root certificates to clients and machines. I really did not want keep distributing my certificates out to every client and server that I have. Granted the root certificates would not be handed out to my Linux servers since they cannot receive Windows group policy.

I did make many errors along the way, due to me not knowing much about how PKI works. I first set up two Windows servers, one was going to act as the root certificate authority, and the other was going to be the subordinate certificate authority. When I set up my root CA I found out that I did not set it up as a offline ca so every time my Sub CA restarted it would not be able to get the certification revocation list. Unfortunately the easiest way to fix this issue was to re-create my root CA. Another thing to note during this journey make sure the root CA lasts for at least 10 years. By default Windows will set the root certificate expiry of two years. In fact if you leave both your root and sub CA with the same expiry length you will only be able to provision certs for a couple of days because you cannot provision certs farther out than the root expiry.

When I created the Sub CA I also added in web enrollment (Well after I had to re-create my sub-CA because I kept running into some odd windows errors). Web Enrollment allows me to navigate to a web browser to https://subca.example.com/certsrv and provision certificates via a webpage rather than uploading CRL to server, and signing the cert then moving the cert back to the client.

Further additions

I ended up diving into another project that I will hope to come back to. I was trying to set up RADSEC on a Cisco 3850 to connect with my freeradius server. In order to do this I needed a certificate on my switch. In order to automatically provision a certificate I had to install Windows Network Device Enrollment. Once again as I wanted to automatically provision certificates I needed to make some changes to Network Device Enrollment.

Side note, NDES (Network Device Enrollment Service) is the most frustrating and annoying Windows service to set up. In order to configure it you need to make some registry changes within:
HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP
I just needed to set it to do two things:

1. Edit the Certificate Template to my RADSEC-Client-Cert which I made from the user certificate template.
2. Set EnforcePassword to 1 in MSCEP\EnforcePassword

I did not want to still have it be a manual process of generating the access code, and going to the switch to renew the certificate. Instead I disabled the password and set a ip whitelist for the site.

IIS IP Whitelist

Like Web Enrollment NDES adds sites via windows IIS (Internet Information Services). I added in an IP Whitelist to the MSCEP site.

Once I had this the switch which has a static IP address would be able to automatically provision and renew its certificate via Windows Network Device Enrollment Services.

Closing Thoughts

As I am doing more with my PKI and expanding it out to meet my needs, I find that I run into many issues with the archaic windows configuration. I was honestly verry surprised how lacking the Windows PKI tools are, seeing certificates are moving more and more important. There is also a push to use certificate automation processes to use short lived certificates.

With the above lacking support of certificate protocols such as ACME, and the slowing distaste for Windows server, I have found myself looking for other options for PKI infrastructure.