Microsoft Exchange Server Auth Certificate

The Microsoft Exchange Server Auth Certificate is one of those components you configure once and then never think about again—until the day it expires and suddenly authentication-dependent services stop working.

In most environments, this certificate sits quietly in the background for five years, enabling OAuth-based authentication between Exchange and other services such as:

  • Exchange Online (hybrid deployments)
  • Skype for Business / Lync
  • SharePoint
  • Office Web Apps / Office Online Server

When it expires, the symptoms can be confusing and wide-ranging. I’ve seen expired Auth certificates cause:

  • Hybrid free/busy failures
  • EWS authentication errors
  • Intra-org connector issues
  • OAuth token validation failures
  • Seemingly “random” service disruptions

The good news? Renewing the certificate is straightforward—as long as you understand what Exchange is actually doing under the hood.

Microsoft Exchange Server Auth Certificate

What Is the Microsoft Exchange Server Auth Certificate?

The Microsoft Exchange Server Auth Certificate is:

  • Self-signed
  • Automatically created during Exchange installation
  • Used exclusively for OAuth authentication
  • Shared logically across all Exchange servers in the org

It is not:

  • A TLS/SSL certificate
  • Used for SMTP, OWA, or HTTPS traffic
  • Issued by a public CA

Its sole job is to sign and validate OAuth tokens between Exchange and trusted partner services.


Why Expiration Causes Disruption (Even If Email Still Works)

When this certificate expires:

  • OAuth token signing fails
  • Dependent services reject authentication requests
  • Exchange continues running—but integrations quietly break

This is why many admins don’t notice immediately. Mail flow still works. OWA still loads. But hybrid features start failing in subtle ways.

In hybrid environments, this certificate is critical. Exchange Online trusts the on-premises Auth certificate thumbprint that was previously published. When the cert expires and isn’t renewed correctly, trust breaks.


Should You Renew Before or After Expiration?

From real-world experience:
The renewal process is identical whether the certificate is expired or not.

Microsoft designed this intentionally. Exchange can:

  • Create a new Auth certificate
  • Stage it alongside the old one
  • Transition trust cleanly

That said, renew before expiry whenever possible. Recovering from an expired cert often means troubleshooting user-impacting issues under pressure.


High-Level Renewal Process (What Exchange Is Actually Doing)

When you renew the Exchange Auth Certificate, Exchange:

  1. Generates a new self-signed Auth certificate
  2. Assigns it a new thumbprint
  3. Updates the AuthConfig to reference the new certificate
  4. Publishes it across the organisation
  5. Retires the old certificate

Understanding this flow helps you avoid skipping critical steps.

Step-by-Step: Renewing the Exchange Auth Certificate

Step 1: Renew the Certificate in Exchange Admin Center

  1. Open Exchange Admin Center
  2. Navigate to Servers → Certificates
  3. Select Microsoft Exchange Server Auth Certificate
  4. Click Renew

This works whether the certificate is valid or expired.

Important: The new certificate is created only on the server where you perform the renewal.

Microsoft Exchange Server Auth Certificate

Step 2: Identify the New Certificate Thumbprint

After renewal:

  • A second certificate with the same name appears
  • It has a new thumbprint
  • It is not active yet

To find the thumbprint:

  1. Open the certificate properties
  2. Go to the General tab
  3. Copy the thumbprint (do not retype it manually)

You will need this exact value for the next steps.


Step 3: Check the Currently Active Auth Certificate

Run the following PowerShell command:

Get-AuthConfig | FL CurrentCertificateThumbprint

This will show the thumbprint Exchange is currently using—which will still point to the old (possibly expired) certificate.


Step 4: Activate the New Auth Certificate

Now activate the new certificate by running:

Set-AuthConfig -NewCertificateThumbprint <NEW_THUMBPRINT> -NewCertificateEffectiveDate <DATE>

Notes from real-world usage:

  • Microsoft recommends setting the effective date 48 hours in the future
  • If recovering from an expired cert, you can use today’s date
  • You will receive a warning—this is expected

In outage scenarios, immediate activation is usually required.


Step 5: Publish the Certificate to All Exchange Servers

This step is critical and often missed:

Set-AuthConfig -PublishCertificate

This distributes the new certificate information across the Exchange organisation and ensures all servers are aligned.


Step 6: Remove the Old Certificate Reference

Once the new certificate is active and published:

Set-AuthConfig -ClearPreviousCertificate

This cleans up the AuthConfig and prevents Exchange from referencing the expired certificate.


Do You Need an IIS Reset?

In most cases, no—Exchange will eventually apply the changes automatically.

However, in real-world recovery scenarios:

  • Running iisreset can speed up validation
  • It can help clear cached authentication tokens
  • It may reduce the wait time when testing hybrid services

I typically reserve IIS resets for:

  • Expired cert recovery
  • Hybrid environments with user impact
  • Situations where testing immediately after renewal is required

Hybrid Environment Considerations (Very Important)

If you are running Exchange Hybrid:

  • Exchange Online must trust the new certificate
  • OAuth trust relies on published metadata
  • Delays can occur before full functionality returns

In stubborn cases, you may need to:

  • Re-run the Hybrid Configuration Wizard
  • Validate OAuth with Test-OAuthConnectivity
  • Confirm federation trust health

This is rarely documented clearly, but it matters.


How to Verify the Renewal Worked

After completing the steps, validate with:

Get-AuthConfig | FL *

Confirm:

  • CurrentCertificateThumbprint matches the new cert
  • No references remain to the old certificate
  • Services relying on OAuth are functioning

In hybrid environments, test:

  • Free/busy
  • EWS access
  • Cross-prem mailbox access

Common Mistakes I’ve Seen in Production

From real-world support cases:

  • Renewing the cert but never activating it
  • Forgetting to publish the certificate
  • Copying the thumbprint incorrectly
  • Removing the old cert too early
  • Assuming IIS reset fixes everything

Most Exchange Auth Certificate issues aren’t caused by complexity—they’re caused by missed steps.


Final Thoughts: A Small Certificate With a Big Impact

The Microsoft Exchange Server Auth Certificate is deceptively simple, but it underpins some of the most critical integration points in modern Exchange deployments—especially hybrid ones.

My advice:

  • Calendar the expiration date
  • Renew it proactively
  • Document the thumbprint change
  • Validate OAuth functionality after renewal

Handled correctly, this renewal takes minutes. Ignored, it can quietly break core services and consume hours of troubleshooting time.

3 thought on “How to Renew an Expired Microsoft Exchange Server Auth Certificate”
  1. What if I have two servers in a DAG environment? Do I Have to make a renew certificate request in both servers? or do I have to export the certificate manually from one server to the second after renewal?
    Thank you

Leave a Reply

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