Exchange server 2007 onwards will generate a self signed certificate as part of the installation process and bind that to multiple services. Those certificates have a 5 year validity, and the process to generate a replacement is pretty straight forward using New-ExchangeCertificate cmdlet.
One spin on this, was that some customers would do a pipe Get-ExchangeCertificate to New-ExchangeCertificate cmdlet using the original certificate as the input. That is documented as example #3.
Granted, I personally have not seen customers do this and I don't do it myself. I typically just specify the options I need and just run the New-ExchangeCertificate. Job done!
What happens though when the original cert is SHA1?
As a brief reminder there were changes made in the Exchange 2016 CU2 timeframe on how Exchange generates self signed certificates. In the olden days, Exchange would only ever generate SHA1 based certificates. That applied to the certificate generated at installation time and on subsequent activities after the server was installed.
As you can see below, even if the source certificate was SHA1 the new certificate will be SHA2.
Exchange 2016 Lab Environment
This environment has Exchange 2013 CU23 and Exchange 2016 CU20 servers. All security updates were installed at the time of writing which was early October 2021.
Let's look at the starting configuration of the TLS certificates.
Get-ChildItem -Path cert:\LocalMachine\My\* | Select Subject -ExpandProperty SignatureAlgorithm | select Subject, FriendlyName
Certificate 1DAE8F75B7787FC3E3CEA9C42CF4D6D257DBA24B is the original Exchange certificate that was created during setup.
Note that this is a SHA1 certificate. The Exchange related certificates were generated afterwards, thus they are SHA2.
Server versions for reference:
Renewing Exchange 2016 Self Signed Certificate Using Pipeline
Since we know the thumbprint of the current self signed certificate, we can use that to pipe it to the New-ExchangeCertificate cmdlet.
This is shown below:
Get-ExchangeCertificate 1DAE8F75B7787FC3E3CEA9C42CF4D6D257DBA24B | New-ExchangeCertificate -PrivateKeyExportable $True
This was a test, so the default SMTP certificate was not updated. For other thoughts on when to update the default SMTP certificate please see.
A new certificate with a tumbprint of 150EFC6FC2F7292FC6804159B9DECCF594F6EB17 was created. It has the same subject as the original.
But if we look at the details for certificate 150EFC6FC2F7292FC6804159B9DECCF594F6EB17, is that a SHA1 or SHA2 certificate?
The first command in the below image shows all certificates, the command listed below retrieves just that one specific certificate.
Get-ChildItem -Path cert:\LocalMachine\My\150EFC6FC2F7292FC6804159B9DECCF594F6EB17 | Select Subject -ExpandProperty SignatureAlgorithm | Select Subject, FriendlyName
As you can see, piping a SHA1 cert to the cmdlet still results in a SHA2.
Exchange 2019 Lab Environment
The below was run to the Exchange 2019 CU10 server in a separate lab. All security updates were installed at the time of writing which was at the start of October 2021.
0B2786D5F5842352116151BC844C2E982543C5AA
Get-ExchangeCertificate 0B2786D5F5842352116151BC844C2E982543C5AA | New-ExchangeCertificate -PrivateKeyExportable $True
As you can see - a SHA2 certificate is also produced.
Cheers,
Rhoderick
