- Manage Microsoft Teams with PowerShell: Create and configure teams, add users - Mon, Oct 12 2020
- Synchronize password hashes using Azure Active Directory Connect (AAD Connect) - Mon, Aug 3 2020
- Install PowerShell for Exchange (Online) on a workstation - Mon, May 11 2020
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 v18.104.22.168 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.
This ensures immediate reassignment of the renewed certificate to all Exchange services.