0

Exchange Self Signed SHA2 Certificates

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.

Exchange 2013 CU12 Based Server

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.

Creating Self Signed Cerificate Using Exchange 2013 CU12

If we look at the properties of the certificate using Get-ExchangeCertificate not all of the details are exposed:

Get-ExchangeCertificate -Thumbprint AFF86BFA0FBC1D492E450937C3434DAE5CD388D0

Get-ExchangeCertificate To See All Properties

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:LocalMachineMyAFF86BFA0FBC1D492E450937C3434DAE5CD388D0 | Select Subject  -ExpandProperty
SignatureAlgorithm | Select Subject, FriendlyName

Using Certificate PS Provider To See All Certificate Properties

Alternatively the certificate MMC can be used:

Viewing Certificate Properties In the Certificates MMC

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:

Exchange 2013 Updated To CU13 - Previous Certificates Still Valid

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.

Creating Self Signed Cerificate Using Exchange 2013 CU13

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:LocalMachineMy45E717BF46626ACDB4338C10FCEB081653AFAD4 | Select Subject  -ExpandProperty SignatureAlgorithm | select Subject, FriendlyName

Using Certificate PS Provider To See All Certificate Properties

This is also visible in the certificates MMC.

Viewing Certificate Properties 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 no 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

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *