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:\LocalMachine\My\AFF86BFA0FBC1D492E450937C3434DAE5CD388D0 | 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:\LocalMachine\My\045E717BF46626ACDB4338C10FCEB081653AFAD4 | 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


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.



Comments (9)

  1. So we leave self-signed certs for Exchange intra-server communication enabled?
    Putting client access aside, what about SMTP TLS connections? That depends on how the connector is configured and if the associated cert is required to be verified. Then we need to use a valid 3rd party certificate.

    1. Hi Thomas,

      Agreed — From the client access aspect, a user should never see a self signed cert.

      For mailflow purposes depends upon the situation and configuration.


  2. I have a client that has Exchange 2010 SP3 CU15. Every time I try to generate a new cert, I get SHA1 rather than SHA256. Is there any switch or parameter I need in the New-ExchangeCertificate PS command? Is there something else I am missing?

    1. Hi Jeremy,

      This is from the top of the post:
      “Additionally, Exchange 2013 CU13 and Exchange 2016 CU2 added support for generating the self signed certificates as SHA2 certs.”

      I have the same behaviour on my lab machine when I generate a new self signed cert on an Exchange 2010 SP3 RU15 box.

      However, friends don’t let friends use self signed certs. When you generate a request and it is signed by an issuing CA, that should come back as a SHA2 cert at this time. So just because the self signed cert is SHA1, that should be an issue.


      1. David Smith says:

        My question is this though. When you have an app pointing to EWS, and it refers you to the backend service on 444, how do you generate that cert as SHA2

        1. Hi David, I’d break that in two pieces

          1- How to generate the SHA2 on a 2013 box and bind it to the backend site
          2 – what is the config used that the app is hitting the back end directly


  3. Hi Rhoderick,
    Again, very helpful article.
    Just wanted to add that you can also find out the SAH1 or SHA2 details using the Get-ExchangeCertificate, as shown in the following example:
    Get-ExchangeCertificate | Select Subject -ExpandProperty SignatureAlgorithm | Select Subject,FriendlyName

    This could be very useful to quickly check multiple Exchange servers (with minor tweak).


    1. Groovy – thanks Feras!


Skip to main content