In recent builds, Exchange has been updated to support the newer SHA2 certificates. Exchange 2010 SP3 RU13 and Exchange 2013 CU 12 updated the SMIME control’s certificate to SHA2.
Additionally, Exchange 2013 CU13 and Exchange 2016 CU2 added support for generating the self signed certificates as SHA2 certs.
The below is for reference to save having to spin up labs in the future to review differences in the SHA1 and SHA2 self signed certificates.
Starting Configuration
This is an Exchange 2013 CU12 server. Exchange 2013 build numbers can be viewed here for reference.
If we create a new self signed certificate using the 2013 CU12 build, a new certificate with a thumbprint of AFF86BFA0FBC1D492E450937C3434DAE5CD388D0 is generated. This certificate is highlighted below.
If we look at the properties of the certificate using Get-ExchangeCertificate not all of the details are exposed:
Get-ExchangeCertificate -Thumbprint AFF86BFA0FBC1D492E450937C3434DAE5CD388D0
So let’s use the the Certificate PS Drive to see all the good stuff. Note that there is a prefix of Cert:\LocalMachine in the below command. We could run something like the below to show the certificate name and the hash algorithm used.
Get-ChildItem Cert:\LocalMachine\My\AFF86BFA0FBC1D492E450937C3434DAE5CD388D0 | Select Subject -ExpandProperty SignatureAlgorithm | Select Subject, FriendlyName
Alternatively the certificate MMC can be used:
Now that we have looked at the older SHA1 cert, let us update Exchange to a new build which will generate self signed certs as SHA2.
Updated Exchange 2013 To CU13
After installing Exchange 2013 CU13, the previously created self signed certificate is still present. This is highlighted below:
Now that Exchange 2013 CU13 is installed, let’s create a new self signed certificate using New-ExchangeCertificate. You will note below that a certificate with thumbprint of 045E717BF46626ACDB4338C10FCEB081653AFAD4 is created.
Checking the signature hash algorithm of the new self signed certificate, we can see that it is now a SHA2 based cert.
Get-ChildItem -Path cert:\LocalMachine\My\45E717BF46626ACDB4338C10FCEB081653AFAD4 | Select Subject -ExpandProperty SignatureAlgorithm | select Subject, FriendlyName
This is also visible in the certificates MMC.
Bootnote
Exchange will create the self signed certificates when the product is installed. However, should they be left enabled? In short, the answer is no.
Generally the phrase I like to use is “Friends don’t let friends use self signed certs”.
When an Outlook client sees a self signed certificate, it will throw the untrusted certificate error. Users should not be told/trained that this is acceptable; else before you know it they will be ignoring certificate warnings across the board clicking to see the dancing pigs. Not good. You may try to configure Outlook Anywhere to not use SSL, but that is not a deployment which is full of #Winning. Regardless of the #Winning level attained, that would only address the RPC/HTTP connection, the certificate warnings to all other web services are a separate issue.
There is one case where the self signed certificate is acceptable -- which is on the Backend site on Exchange 2013 or 2016. Users do NOT connect directly to that site, connections are proxied to the Back End web site. Note that the Back End site listens on 81 TCP and 444 TCP.
Cheers,
Rhoderick
