In part 1 preparations have already been made for Let's Encrypt certificates and Exchange 2010. This article therefore builds directly on Part 1 on.
In Part 1, the Exchange organization was adapted accordingly, so in Part 2 we will continue directly with the configuration of the public DNS.
I forgot to mention that the entire environment is installed on Windows Server 2008 R2. I deliberately chose Server 2008 R2 because it is a widely used platform for Exchange 2010.
Public DNS
In order for Exchange to be accessible via the Internet, the corresponding DNS entries must also be created on the public DNS server. In my case, I use Strato as my provider, so the DNS entries are also created there. So that Let's Encrypt can validate the DNS names that will later appear on the certificate, the Let's Encrypt CA must be able to reach the Exchange server via port 80 (http). Therefore, the 3 DNS names are also made known to the public DNS server:
- autodiscover.frankysweb.org
- outlook.frankysweb.org
- outlook.int.frankysweb.org
The DNS names each refer to the public IP of the Exchange server. In this scenario, it is the WAN IP of the router:
The router has configured a port forward for port 80 and 443 to the Exchange Server:
It must therefore be ensured that the configured DNS names from the first part are also accessible from the Internet. In principle, this is very easy to check, if an IIS test page can be called up under each URL, the configuration is correct.
At this point, the browsers may still display a certificate warning, as the valid certificate must first be requested.
Let's Encrypt
My demo environment runs on Windows Server 2008 R2. I have deliberately installed the Exchange 2010 Server on Server 2008 R2, because this constellation is probably still quite widespread.
Server 2008 R2 is delivered with PowerShell 2.0, which is no longer up-to-date and must therefore be updated so that the following script works.
PowerShell 4 is supported for Server 2008 R2 and Exchange 2010, so the Windows Management Framework 4.0 can be installed:
Windows Management Framework 4.0
The Windows Management Framework contains, among other things, PowerShell version 4. After installation, the command "get-host" should display version 4 of PowerShell:
Note: The Exchange Management Shell is still started with PowerShell 2, this is normal and does not cause any problems for the rest of the process:
After the PowerShell version has been updated, PowerShellGet must be installed, only then are the necessary CMDLets available to install the LetsEncrypt client. The corresponding download can be found here:
After PowerShellGet has been installed, the CMDLets are ready for installation, now the Let's Encrypt Client "ACMESharp" can be installed:
install-module -name ACMESharp
Now it is almost done, because the current version of the "Certtificate Assistant" now also supports Exchange 2010.
Note: Björn has adapted the original "Certificate Assistant" so that it also works with Exchange 2010. His modifications worked perfectly in my environment. I then fixed another bug that was my fault. So thanks to Björn at this point!
The current version of the "Certificate Assistant" is available here:
After the download, the script only needs to be executed with PowerShell 4. Please do not use the Exchange Management Shell, but the previously updated version of the "normal" Windows PwoerShell.
A task for automatic renewal of the certificate can also be created directly in the script:
If you have not yet registered with Let's Encrypt, the following error will be displayed:
The script then carries out the registration, requests the certificate and assigns it to the Exchange server:
