- Microsoft Graph: A single (PowerShell) API for Microsoft’s cloud services - Tue, Aug 23 2022
- Exchange impersonation: Grant permissions to service accounts - Mon, Aug 8 2022
- Send Microsoft Teams meeting invitations in multiple languages - Thu, Jul 21 2022
The CA of Let's Encrypt issues certificates for individual hosts or subject alternative name (SAN) certificates. There's been support for wildcard certificates since the beginning of 2018. Note that the certificates are only valid for 90 days. Therefore, it is advisable to set up an automatic process for regular renewal.
Numerous ACME clients
To verify that applicants control the domains they wish to issue certificates for, Let's Encrypt uses the Automatic Certificate Management Environment (ACME) protocol.
Version 2.0 is currently available as a beta and requires the .NET Framework 4.7.2. In my lab, the tool crashed right at the start; hence, I have used the stable v220.127.116.11 instead. If you want to request wildcard certificates, you need the ACME2 protocol, which this tool supports only from version 2.0 onwards.
Verification requires accessibility via the internet
No matter which method of verifying the domain you choose, they all have in common that the fully qualified domain name (FQDN) must be resolvable via a public DNS server and the host must be reachable via the internet on port 80.
This is also true if you decide to verify domain ownership using a file, which the client downloads to the local computer. You have to copy it to the host where it must be accessible for Let's Encrypt.
In our example, we let win-acme read the bindings of an IIS site; hence, the ACME client determines the hostnames from the IIS configuration. Therefore, we have to make sure in the IIS Manager that HTTP is bound to the respective FQDN at the desired sites.
Interactive request of the certificate
We then decide on 3, which is "SAN Certificate for all bindings of multiple IIS sites." Exchange has had two IIS sites since version 2013 that need a certificate. After that, we choose option 3 "[http-01] Create temporary application in IIS" as the method.
After it successfully issues the certificate, letsencrypt.exe will store it under C:\ProgramData\win-acme\httpsacme-v01.api.letsencrypt.org\.
The ACME client then offers creating a scheduled task for automatic certificate renewal. In a pure IIS environment, you will use this, so the process is now finished at this point.
If everything went well, IIS should now have the certificate installed. If not, you can quickly assign it manually in the IIS Manager.
Assigning a certificate to POP, IMAP, or SMTP
If you need the certificate for Exchange, then not all services have a certificate at this point. You could now assign it manually in the web console; instead, we will use the script ExchangeLetsEncrypt.ps1 by Anthony Eden.
It requires two parameters: CertificateImport (for the path to the PFX file Let's Encrypt has generated, usually at C:\ProgramData\¬letsencrypt-win-simple\¬httpsacme-v01.api.letsencrypt.org\) and RDCB (the server's FQDN).
Extending a certificate
Because the validity of the certificate is limited to 90 days, you must be careful not to miss its renewal. It is best to set up a scheduled task that should not only contain the ACME client with the renewal parameter but also the PowerShell script mentioned above to assign the certificate to all Exchange services:
C:\inetpub\letsencrypt\letsencrypt.exe --renew --baseuri https://acme-v01.api.letsencrypt.org/powershell.exe -File "C:\inetpub\letsencrypt\ExchangeLetsEncrypt.ps1" -CertificateImport "C:\ProgramData\win-acme\httpsacme-v01.api.letsencrypt.org\NAME-of-the-CERTIFICATE.com-all.pfx" -ServerName ex01.domain.com
The script author provides a batch file (ExchangeInstallLE.bat) that contains these two commands; you only need to adapt it to your own environment.
Subscribe to 4sysops newsletter!
This ensures immediate reassignment of the renewed certificate to all Exchange services.