The security space is constantly evolving, and while a lot of the recent work has been on moving to TLS 1.2, a previous focus in the industry was to stop issuing SHA1 certificates and transition to SHA2 based certificates. As a result, many will run security scans to review the presence of installed certificates and their properties. In one such engagement, the security team noted their displeasure after Exchange 2016 was installed as they detected SHA1 certificates on all of these brand new servers.
You may recall that Exchange previously added support for Exchange 2013 and newer to create SHA2 self signed certificates back in 2016. This was discussed here.
To illustrate the situation, let’s install a brand new Exchange 2016 CU18 server onto a fully patched Windows Server 2016 OS. At the time of writing CU18 was the latest release.
Installed Exchange 2016 CU18 onto a fully patched Windows Server 2016 machine. This server is called Exch-2016.
The install completes successfully.
Reviewing Default Certificate Configuration
After setup completed, the server was restarted. The starting certificate configuration is shown below. Note that this is an Azure VM which accounts for the Azure certificate and WinRM is configured – that is the WMSvc certificate.
The bottom certificate is the Federation certificate which was automatically copied by Exchange to this server. All servers in the organisation need access to the same Federation and Auth certificate. This is expected behaviour.
Certificate 062CCABC7FC2A21AAA55A07C04E5FD34752EABDC is the default Exchange self signed certificate. We know this by it’s 5 year validity, the fact it is self signed and the subject name is the NetBIOS name of the server.
Looking at the certificate, we can see that it is issued by Exch-2016 to Exchange-2016 – in other words issued to itself by itself.
Checking the Details tab shows that it is a SHA1 certificate.
There is nothing interesting on the Certification Path tab as it is a self signed certificate.
Hmm. What about that blog post above that said Exchange can now generate SHA2 certificates? Is that no longer correct?
Generate A Certificate Post Install
Let’s generate a new certificate and see if that is SHA1 or SHA2 based. It was given a different friendly name to easily identity it.
The new certificate has thumbprint 631D408A2F5699E30771304CEA53FDC1D2C6E3CC
In the certificate MMC, we can see the new Exch-2016-V2 certificate.
Well this is different right in the General tab. This new certificate is NOT trusted automatically.
It is however a SHA2 certificate.
Should you want, PowerShell can also show the same information. For example:
Get-ChildItem Cert:\LocalMachine\My\631D408A2F5699E30771304CEA53FDC1D2C6E3CC | Select Subject -ExpandProperty SignatureAlgorithm | Select Subject, FriendlyName
Two things should be apparent. And both are important.
The Exchange install process continues to generate SHA1 certificates. You need to manually replace these certificates on a newly built machine if your security policy states that all certificates must be SHA2.
Secondly, running New-ExchangeCertificate does NOT automatically mark the certificate as trusted. While this is OK for proxying to the Exchange Back End web site on TCP 444 and opportunistic SMTP it causes problems for Managed Availability.
See this post for the Managed Availability issues and resolution.
I will not speculate for the reason behind these differences, please be aware of them and the potential impact to your environment.