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.

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:
- Generates a new self-signed Auth certificate
- Assigns it a new thumbprint
- Updates the AuthConfig to reference the new certificate
- Publishes it across the organisation
- 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
- Open Exchange Admin Center
- Navigate to Servers → Certificates
- Select Microsoft Exchange Server Auth Certificate
- 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.

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:
- Open the certificate properties
- Go to the General tab
- 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
iisresetcan 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:
CurrentCertificateThumbprintmatches 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.

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.

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
no. the auth cert is stored in active directory, so it will be published to all servers.
Hey Fatma, Same question about DAG? how do you did at the end?