Get-ExchangeCertificate Returns Blank with a Valid Auth Certificate

While validating a fresh Exchange Server 2019 CU15 installation, I started capturing the default configuration before making any namespace, certificate, or authentication changes.

One of the first checks was Get-ExchangeCertificate. Unexpectedly, the cmdlet returned only the column headers and no certificate objects, even though the Exchange Admin Center showed the certificates normally.

Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                --------   -------

At first, this looked like the known Exchange Auth Certificate issue associated with PowerShell Serialization Payload Signing. However, the Auth Certificate was present, valid, correctly configured, and Microsoft’s validation script reported no problem.

What initially looked like a certificate problem eventually turned out to be related to the timing of certificate activation and HMAC key selection.

Certificates were present and the Auth Certificate was valid

The Exchange Admin Center showed all certificates correctly, including the Microsoft Exchange Server Auth Certificate with a valid status.

I then checked the Exchange Auth configuration and validated it with Microsoft’s MonitorExchangeAuthCertificate.ps1 script.

Get-AuthConfig | Format-List CurrentCertificateThumbprint,NextCertificateThumbprint,NextCertificateEffectiveDate

.\MonitorExchangeAuthCertificate.ps1

The current Auth Certificate matched the certificate visible in EAC, and the Microsoft script reported:

Current Auth Certificate is valid for 1799 day(s)
Test result: No renewal action is required

So this was not the usual expired or missing Auth Certificate scenario.

PowerShell Serialization Signing was the trigger

Exchange logs PowerShell serialization activity under:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\Data\Serialization

The log confirmed that certificate-based signing of PowerShell serialization payloads was enabled:

SerializationSigningEnabled = True

For troubleshooting only, I temporarily disabled Serialization Payload Signing. Immediately afterwards, Get-ExchangeCertificate returned all certificates normally.

After removing the temporary override and returning Serialization Signing to its default enabled state, the cmdlet became blank again.

This isolated the problem to the serialization signing path. Disabling Serialization Payload Signing is not a permanent fix and should only be used as a controlled troubleshooting test.

The important clue: HmacCryptoProvider activeKey==null

The Data Serialization log showed the actual failure:

Sign Serialization Failed Error =
Microsoft.Exchange.Diagnostics.ExAssertException:
ASSERT: HmacCryptoProvider.HmacProvider:activeKey==null

Exchange could see the certificate objects, but the HMAC provider used to sign the serialized PowerShell data did not have an active signing key.

This explains why the command appeared to return nothing even though the certificates were visible in EAC.

Replacing the Auth Certificate did not fix it immediately

To rule out a damaged Auth Certificate, I forced creation of a new Auth Certificate with Microsoft’s MonitorExchangeAuthCertificate.ps1 script. The new certificate became the Current Auth Certificate, existed in the Local Computer certificate store, had a private key, and remained correctly configured after service restarts and a server reboot.

However, Get-ExchangeCertificate was still blank.

This is the point where certificate activation time becomes important. Microsoft documents NewCertificateEffectiveDate as the date when the certificate configured as Next should start being used. When testing or setting this value manually, using an explicit UTC value helps avoid ambiguity between local server time and the effective time being evaluated:

Set-AuthConfig -NewCertificateThumbprint <Thumbprint> `
-NewCertificateEffectiveDate (Get-Date).ToUniversalTime()

The UTC and time-zone test

The Exchange server in this test was running in UTC+3.

The newly created Auth Certificate already appeared as Current in Get-AuthConfig, but the serialization subsystem continued to report:

HmacCryptoProvider.HmacProvider:activeKey==null

As a controlled lab test, I temporarily moved the server clock four hours forward. I did not change the certificate or disable Serialization Signing.

Get-ExchangeCertificate immediately started returning all certificates.

This strongly indicates a time-based certificate activation or validation condition in the HMAC key-selection path. It also explains reports where administrators renew an Exchange Auth Certificate, reboot the server, and still see the problem for several hours before it starts working.

Important: advancing the server clock is not a production fix and can break Kerberos and other time-sensitive services. It was used only to prove the timing dependency.

What should you check?

If Get-ExchangeCertificate returns blank while certificates are visible in EAC, check the following before repeatedly creating new certificates:

• Verify the Current Auth Certificate with Get-AuthConfig.
• Run MonitorExchangeAuthCertificate.ps1.
• Check the Data Serialization logs for HmacCryptoProvider.HmacProvider:activeKey==null.
• Confirm whether the Auth Certificate was created or rotated recently.
• Pay attention to NewCertificateEffectiveDate and UTC versus local time.
• Allow the certificate activation window to pass before assuming the replacement failed.

Conclusion

A blank Get-ExchangeCertificate result does not always mean that the Exchange Auth Certificate is expired or corrupt.

In this case, the Auth Certificate was valid and visible, but PowerShell Serialization Signing failed because the HMAC provider had no active key. Temporarily disabling Serialization Signing made the cmdlet work, and advancing the server clock beyond the certificate activation window also made it work while signing remained enabled.

The key lesson is simple: after a fresh Exchange installation or Auth Certificate rotation, do not overlook certificate effective time and UTC/local-time differences. A certificate can already appear as Current while another Exchange component is not yet using it as the active signing key.

References

• Microsoft Support – Certificate signing of PowerShell serialization payload in Exchange Server
• Microsoft Learn – Maintain the Exchange Server OAuth certificate
• Microsoft CSS-Exchange – MonitorExchangeAuthCertificate