In this post we will talk about using the CryptLE on Windows to quickly generate and renew certificates for your virtual appliances with LetsEncrypt (which was not originally designed to provide certificates for virtual appliances).
cheap smart person that I am, I run my small cloud setup (Domain + SSL) completely for free. For DNS I am using ClouDNS and can wholeheartedly recommend them (3 free domains, easy UI, all the features you need for a small size operation, including Web Redirect and mail forwarding). For SSL I am using LetsEncrypt.
LetsEncrypt is awesome, but it was designed for web servers, where things can be highly automated, secure and worry free. But when you need to generate a cert that has to be manually uploaded onto a virtual appliance (such as UAG) – things get a lot more complicated. Suddenly, many LE clients don’t even support this mode! In my case, when I started with LetsEncrypt, no known (to me!) Win32 agent supported issuing a certificate for a different hostname, so I had to deploy a Linux VM, deal with manual DNS challenges (according to my good colleague Alexey Rybalko, there is a DNS provider that does it for you, but $$$), copy the certs to my Windows laptop, from which I then had to deliver certs further. Oh, the mess!…
All this time I was keeping an eye on other Win32 LE clients, in case I missed something, and I’ve found one that does it better. Enter CrypeLE!
So, why is this better?
- Native Win32
- Supports standalone, SAN and wildcard certs
- Can generate a proper LetsEncrypt account so you don’t have to deal with manual DNS challenges every time you renew your cert
- Simple to deploy – one executable
- Simple to use – one-time setup, and then just automate the way you like. I just wrote a CMD file (see below)
Setting up CryptLE
First, we download the 32/64 bit version from https://github.com/do-know/Crypt-LE/releases
Then we read the first time setup guide: https://zerossl.com/usage.html#First_time_run_and_regular_use
Since we don’t want to use manual challenges every time to renew, we will use crypto keys to authenticate instead. We need one domain key per each domain that we want to use, and one account key (same for all our domains). You can use OpenSSL to generate the RSA keys yourself, as the guide recommends, or you can let LE64 generate all that for you with the –generate-missing parameter, as you will see in the next session.
Issuing the certs
In my case I wrote a CMD file that generates a wildcard cert. You need to replace the parts in bold with your parameters.
.\le64.exe ^ -key .__LETSECRYPT_ACCOUNTKEY_PRIVATE.pem ^ -email your_email@your_domain.com ^ -domains "*.%1" ^ -crt "%1-wildcard.crt" ^ -csr-key "%1-wildcard.key" ^ -csr "%1-wildcard.csr" ^ -export-pfx "PFX_PASSWORD" -tag-pfx ".%1" ^ -handle-as dns -api 2 -live ^ -generate-missing
Then you just run it as gen_wildcard.cmd domain.com to get a wildcard cert for *.domain.com stored in a file.
In fact, you get four files, all of which are important!
- .KEY (cert private key) and .CSR (cert signing request, signed with the above key) – these are files that allow you to avoid DNS challenge next time you renew. Keep them! But if you lose them – no problem, you will just have to go through the DNS challenge again
- .CRT – this is a BASE64 encoded public cert (also known as PEM). It alone is enough in most cases, but remember that the private key is stored separately in the KEY file, should you need it.
- .PFX – this is the cert with the key inside in the PFX format, protected with the password you set in the batch file. Different systems require different formats so I always generate both PEM and PFX. Typically PFX is easier for manual installs, and PEM/KEY is easier for automated installs, such as UAG deployment via the INI file.
This is all there is to it!
- Note that first time you run the file, you will have to go through the manual DNS challenge – this is unavoidable – you have to prove ownership of the domain. But next time you do it – it will be all automated, provided you kept the KEY and CSR files.
Loading an account key from .__LETSECRYPT_ACCOUNTKEY_PRIVATE.pem Loading a CSR from <domain>.csr Registering the account key The key is already registered. ID: ... Current contact details: <my email here> Received domain certificate, no validation required at this time. Requesting issuer's certificate. Saving the full certificate chain to <domain>.crt. Exporting certificate to <domain>.pfx. The job is done, enjoy your certificate!
- Another nice effect of having the account key and email is that LetsEncrypt will be sending you the expiration reminders – in the past I almost always missed the deadlines 🙂
- Finally, you can issue SAN certificates too – just specify several domains in the -domains parameter. You will probably not run this in a standard batch file, but it is totally doable – I did it.
We’ve just seen how we can use LE64 / ZeroSSL CryptLE to issue LetsEncrypt certificates (inclding wildcard and SAN) with minimal effort on Windows machines. Was is useful for you? Are you using a better solution? Let me know in comments!
If you have Windows servers on which you want to update the certificates using LetsEncrypt (directly), check out this post by my good colleague Roch Norwa: https://digitalworkspace.blog/2020/01/03/automating-lets-encrypt-cerificates-lifecycle-for-horizon-and-unified-access-gateway/