Creating a wildcard cert on Windows using LetsEncrypt

While in theory you can easily generate internal certificates for internet-based usage, as long as you deploy your CA’s trusted root certificate, there are times (e.g. Windows Autopilot + AAD Join + Co-Management Settings + CMG) when that’s just not practical. But since you can easily get free certificates these days, it’s worth some effort to generate an SSL certificate that is already trusted by devices on the internet.

I’ve been using the https://letsencrypt.org/ service for some time, but mostly on MacOS and Linux. But here’s a case where I wanted to do this on Windows. Step #1 is to install the “Certbot” utility, available for download from GitHub. You can follow the instructions from https://certbot.eff.org/instructions?ws=other&os=windows&tab=wildcard. The installation is trivial:

After it’s installed, you can run “certbot” from the command line. Since I’m going to use this wildcard cert in different ways, I just need to get it manually. The command line to do that:

certbot certonly --manual -d *.contosomn.com -d contosomn.com --agree-tos --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --key-type rsa

That will prompt for you do adjust your DNS settings to add a new TXT record (easier than getting my Windows server directly on the internet to do an HTTP validation). (The “–key-type rsa” switch was added later when I found out the CMG wouldn’t accept the default ECDSA key type.)

I use https://GoDaddy.com for my DNS domain, so I can add the TXT record through their web console:

You’ll have to repeat that process for a second TXT record (add the record, don’t replace the first one), and then you’ll get the cert:

The certificate is only good for three months, so you have to repeat that process every so often, which I’m sure I’ll forget to do — ideally you would add a script that then deploys the cert, but that’s too much work for my lab, so I’ll take care of this manually.

But now I’ve got .PEM files for the private and public keys. That’s rarely what I need when dealing with Windows or Azure — they want a .PFX file. So how do you convert the .PEM files into a .PFX? That’s more trouble than it should be, but I typically use OpenSSL to do that — but then you need that binary, which is more work than it should be, since https://openssl.org doesn’t provide binaries. They do provide links to sites that do provide binaries at https://wiki.openssl.org/index.php/Binaries. I used the “Win64 OpenSSL v3.1.2 Light” MSI from https://slproweb.com/products/Win32OpenSSL.html. (Yes, the web site looks like it’s from the 90’s.) Once it is installed, it has a command prompt that sets up the path to the executable, so you can then just run the needed command:

In this case, I’m pointing it at the output from Certbot, where it puts the latest files as links in the location I specified; each time the certs are renewed (using the same certbot command above), those links are updated, so you would need to re-run this command after each renewal.

With the resulting “wildcard.pfx” file, I can add that as the SSL certificate on any website in the contosomn.com domain (including an SCCM CMG) and it will work.