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.
Lab Install
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
Bootnote
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.
Cheers,
Rhoderick
Hi Rhoderick,
This issue is solved yay!
Exchange Server 2019 and 2016 certificates created during setup use SHA-1 hash (KB5006983)
https://support.microsoft.com/en-us/topic/exchange-server-2019-and-2016-certificates-created-during-setup-use-sha-1-hash-kb5006983-83282c37-1cbf-4a9d-b6a6-8390fac42eeb
Symptoms
Currently, the New-ExchangeCertificate cmdlet uses the SHA-256 hash algorithm instead of the less secure SHA-1. However, the automatic creation of a default self-signed authentication certificate that occurs during the Setup program calls a different code path than the path that's called by the cmdlet. This causes the program to issue certificates by using the SHA-1 hash algorithm.
Resolution
To fix this issue, install one of the following updates:
Cumulative Update 11 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019
Cumulative Update 22 for Exchange Server 2016 or a later cumulative update for Exchange Server 2016
Indeed! It's about time.
It only took a few years to do that 🙂
The two separate code paths and only updating the cmdlet code back in 2016 was always annoying. I just spent a few hours this week with a customer to update all of their older SHA1 certs and the AUTH cert so that they are all SHA2 and the security team can stop bugging them.
Cheers,
Rhoderick
I'm fighting with edge transport servers and certificates right now ... put a SHA256 on an edge server and it indicated we needed to re-do the edge subscription. Did that but am now reading that the edge sync process only supports SHA1? We've got "Could not decrypt EdgeSync credential" errors in our event logs. Have only started digging around on this but when I read this blog post it made me wonder if MS added only partial support? Operating on Exchange 2016.