Renewing the Exchange Self-Signed Certificate: A Step-by-Step Guide

If you’ve managed Microsoft Exchange for any length of time, you’ve probably encountered certificate warnings, expired cert alerts, or unexplained IIS and OWA failures that mysteriously appear after a routine maintenance task.

One of the most commonly overlooked — yet critical — certificates in an Exchange environment is the Exchange self-signed certificate.

While Microsoft strongly recommends using a trusted third-party CA certificate for external client access, the self-signed certificate remains essential for internal Exchange service-to-service communication, particularly between IIS sites and backend services.

Letting this certificate expire — or renewing it incorrectly — can cause:

• OWA and ECP loading blank pages
• ActiveSync failures
• Exchange Management Shell connection errors
• WinRM and PowerShell remoting failures
• Event log noise that hides real issues

In this guide, I’ll walk through how to properly renew the Exchange self-signed certificate, explain why things break when they do, and share real-world lessons that aren’t covered in most documentation.

What Is the Exchange Self-Signed Certificate Actually Used For?

The Exchange self-signed certificate is automatically created during Exchange installation and is typically named “Microsoft Exchange”.

It’s primarily used for:

• Internal IIS communication
• SMTP (internal transport)
• Exchange Back End website (port 444)
• PowerShell remoting
• Service authentication between Exchange components

Important:
This certificate is not the same certificate you use for Outlook Anywhere, OWA, or external HTTPS access. Replacing your public CA certificate will not fix issues caused by an expired self-signed cert.

Depending on your Exchange version, this certificate is usually valid for 1–5 years. When it expires, Exchange does not always fail gracefully.

When Should You Renew the Exchange Self-Signed Certificate?

Ideally, before it expires.

In the real world?
Most admins find out after users start calling.

You should renew the certificate when:

• It’s within 30–60 days of expiration
• You see certificate expiration warnings in Event Viewer
• You’re performing other Exchange maintenance
• You’re troubleshooting unexplained IIS or EMS issues

Step 1: Identify the Expired or Expiring Certificate

Start by opening the Exchange Management Shell as an administrator.

Run:

Get-ExchangeCertificate | fl

Look for:

• Subject = Microsoft Exchange
• NotAfter date close to or past expiration
• Services assigned (IIS, SMTP, etc.)

Take note of the Thumbprint — you’ll need it in the next step.

Pro tip:
Don’t assume the oldest certificate is the right one. I’ve seen environments with multiple self-signed certs due to failed renewals.

Step 2: Renew the Self-Signed Certificate (The Correct Way)

Once you have the thumbprint, run:

Get-ExchangeCertificate -Thumbprint "THUMBPRINT" | New-ExchangeCertificate

Example:

Get-ExchangeCertificate -Thumbprint "BFD0FA04DE0A65F17E6EC949407E633ABFFFBCCB" | New-ExchangeCertificate

You’ll be prompted to confirm overwriting the existing certificate.

When complete:

• A new self-signed certificate is generated
• Exchange attempts to reassign services automatically

Real-world insight:
Automatic reassignment works most of the time — but IIS bindings are where things often go wrong.

Step 3: Verify Service Assignments

Check the newly created certificate:

Get-ExchangeCertificate | fl

Confirm that required services are assigned, typically:

• IIS
• SMTP

If IIS is missing, assign it manually:

Enable-ExchangeCertificate -Thumbprint "NEWTHUMBPRINT" -Services IIS,SMTP

Common Problem: IIS Binding Breaks After Renewal

This is where many Exchange admins get caught out.

Symptoms You’ll See

• OWA or ECP shows a blank page
• ActiveSync stops syncing
• Exchange Management Shell fails to connect
• PowerShell errors like:

The WinRM Shell client cannot process the request
Failed to connect to an Exchange server in the current site

Why This Happens

Exchange uses two IIS websites:

• Default Web Site – front-end, uses your public CA cert
• Exchange Back End – internal proxy, uses the self-signed cert on port 444

When the self-signed certificate is renewed, the Exchange Back End binding may be removed or left pointing to the old cert.

Step 4: Fix the Exchange Back End Certificate Binding

Perform these steps on the Mailbox server.

1. Open IIS Manager
2. Expand Sites
3. Select Exchange Back End
4. Click Bindings

5. Select https on port 444
6. Click Edit
7. Select the Microsoft Exchange self-signed certificate
8. Click OK

Then open an elevated command prompt and run:

iisreset

Field experience:
I’ve fixed more “Exchange is down” incidents with this exact binding check than any other single task.

Step 5: Remove the Old Certificate (Optional but Recommended)

Once you’ve confirmed:

• OWA loads correctly
• ActiveSync is working
• EMS connects
• Mail flow is healthy

You can safely remove the expired certificate:

Remove-ExchangeCertificate -Thumbprint "OLDTHUMBPRINT"

⚠️ Be cautious here — never remove a certificate until you’re 100% sure the new one is fully functional.

Should You Restart Exchange Services?

In most cases, no.

However, if you’re troubleshooting lingering issues:

• Restarting the Microsoft Exchange Transport service can help
• An IIS reset is usually sufficient
• Avoid rebooting unless absolutely necessary

Post-Renewal Checklist (What I Always Verify)

After renewing an Exchange self-signed certificate, I always check:

✅ OWA and ECP access
✅ ActiveSync connectivity
✅ Exchange Management Shell connection
✅ Mail flow (internal and external)
✅ Event Viewer for certificate warnings
✅ Certificate expiration dates documented

Best Practices to Avoid Future Certificate Pain

Based on real-world experience:

• Monitor Exchange certificate expiry proactively
• Document renewal dates during upgrades
• Don’t rely solely on automatic bindings
• Treat self-signed certs as production-critical assets
• Review certificates after every CU installation

Final Thoughts: Don’t Underestimate the “Internal” Certificate

Renewing the Exchange self-signed certificate is technically simple — but operationally risky if you don’t understand how Exchange uses it behind the scenes.

Most Exchange outages I’ve seen related to certificates weren’t caused by expiration alone, but by incomplete renewals, missing IIS bindings, or assumptions that “Exchange will handle it.”

Handled properly, this process takes 10–15 minutes.
Handled incorrectly, it can cost you hours of downtime and a flood of user tickets.

If you’re still running on-prem Exchange, this is one maintenance task worth mastering.

Daniel Lutton

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.