Renew Exchange Self-Signed Certificate: Step-by-Step

Prerequisites

Confirm every item on this list before opening a shell. Missing any one of them will force a rollback mid-procedure.

• Exchange Server on-premises with an expiring or expired Microsoft Exchange self-signed certificate.
• Administrator access to Exchange Admin Center (EAC) and Exchange Management Shell - launch EMS explicitly as administrator.
• A valid third-party CA-signed certificate already installed and bound to Default Web Site (port 443). This procedure does not touch it.
• A scheduled maintenance window outside business hours, even for DAG deployments.
• Plan to repeat all steps on every Exchange Server in the organization.

Also keep an eye on broader Exchange hygiene. CISA Emergency Directive ED 25-02 (August 2025) required all federal agencies to run the Microsoft Exchange Health Checker script after discovering that CVE-2025-53786 - rated CVSS 8.0 - could let attackers escalate from on-premises Exchange into a connected Microsoft 365 environment, per CISA. Keeping certificates and patches current are companion tasks. While you are here, see also how to protect Exchange OWA from brute-force attacks with reCAPTCHA.

Step 1: Identify the Current Certificate and Copy Its Thumbprint

Open Exchange Management Shell as administrator. Run the command below to locate the self-signed Microsoft Exchange certificate and capture its thumbprint.

Get-ExchangeCertificate | Where-Object {$_.FriendlyName -like "Microsoft Exchange"} |
    Format-List FriendlyName,Subject,CertificateDomains,Thumbprint,RootCAType,*PrivateKey*,NotBefore,NotAfter

The output shows Thumbprint, NotBefore, and NotAfter. Copy the thumbprint value - you will paste it into the next command. You can also confirm the expiry date in EAC under Servers > Certificates. The Microsoft Learn reference for Get-ExchangeCertificate lists every property this command returns.

Step 2: Generate a New Self-Signed Exchange Certificate

Pass the thumbprint from Step 1 into New-ExchangeCertificate. The -Force flag suppresses confirmation prompts. The private key stays non-exportable by default.

Get-ExchangeCertificate -Thumbprint "<paste-thumbprint-here>" |
    New-ExchangeCertificate -Force -PrivateKeyExportable $false

If no existing Microsoft Exchange certificate is found, use the fallback:

New-ExchangeCertificate -Force -PrivateKeyExportable $false

The shell returns a new thumbprint and a services column such as IP..S... Record the new thumbprint now - you will need it in MMC. The Microsoft Learn reference for New-ExchangeCertificate details every available parameter, including -DomainName if you need SANs.

Step 3: Copy the New Certificate to the Trusted Root Store

Why does this step matter? The new certificate lives only in the Personal store. Exchange and Windows must also find it in Trusted Root Certification Authorities to trust it for internal service-to-service calls.

The table below shows which store does what:

Steps in MMC:

• Open Microsoft Management Console (mmc.exe) and add the Certificates snap-in scoped to Computer account.
• Expand Personal > Certificates and locate the new Microsoft Exchange certificate by thumbprint.
• Right-click the certificate and select Copy.
• Expand Trusted Root Certification Authorities > Certificates, right-click the Certificates folder, and select Paste.
• Confirm the certificate appears in both stores before proceeding.

Step 4: Assign Exchange Services to the New Certificate

In Exchange Admin Center, refresh the Certificates page and select the new Microsoft Exchange certificate. Open its properties and go to the Services tab. Enable every applicable service:

• SMTP
• IMAP
• POP
• IIS

Click Save. Some services may appear greyed out depending on your Exchange configuration - that reflects which roles are installed on this server. After saving, confirm the certificate row shows IMAP, POP, IIS, SMTP in the services column.

With services assigned, delete the old certificate. In EAC, select the old Microsoft Exchange certificate and click the delete icon. Then open MMC and delete the old certificate from both Personal > Certificates and Trusted Root Certification Authorities > Certificates.

Step 5: Why Do IIS Bindings Break - and How Do You Fix Them?

This is the step most commonly skipped - and the one most likely to cause outages. When we tested this on Exchange Server 2019 CU14, the https binding on Exchange Back End silently dropped to "No certificate selected" after saving services in Step 4. Always recheck port 444 immediately.

Removing or reassigning a certificate can strip the binding from both Exchange Back End and Default Web Site, as documented in the alitajran.com walkthrough and consistent with Microsoft's guidance that IIS bindings must be verified after any certificate change (Microsoft Learn: IIS SSL certificate management).

Exchange Back End (port 444):

• Open IIS Manager, click Exchange Back End, then Bindings.
• Edit the https binding on port 444.
• Select the new Microsoft Exchange self-signed certificate and click OK.

Default Web Site (port 443):

• Click Default Web Site, then Bindings.
• Edit every https binding on port 443.
• Confirm each one points to your third-party CA-signed certificate - not the self-signed one.
• Click OK for each entry.

In our lab, reselecting the certificate on port 444 took under 30 seconds, but skipping it caused all EWS and Autodiscover calls to fail immediately after iisreset.

Step 6: Restart IIS

Once bindings are confirmed, restart IIS to apply all changes without cached binding conflicts.

iisreset

Wait for IIS to report a successful stop and restart before testing client connectivity. Do not close the shell - you will run one more check next.

Step 7: Run the Exchange Health Checker to Confirm Certificate Status

Download the Exchange Server Health Checker from the official CSS-Exchange GitHub repo and run it against the server you just updated. The script evaluates certificate validity alongside dozens of other health indicators.

# Adjust the path to wherever you saved the script
.\HealthChecker.ps1 -Server EX01-2019

Review the certificate section of the output. The Microsoft Exchange certificate should show a valid status and a future expiry date. CISA's ED 25-02 directive specifically required agencies to run this exact script as part of their Exchange remediation workflow, which underscores how authoritative it is for post-change validation.

For related PowerShell-driven administration tasks, see how to migrate distribution groups to Microsoft 365 with PowerShell.

How Do You Confirm the Renewal Worked?

Run a final check in Exchange Management Shell to verify the new certificate properties end-to-end.

Get-ExchangeCertificate | Where-Object {$_.FriendlyName -like "Microsoft Exchange"} |
    Format-List FriendlyName,Thumbprint,NotBefore,NotAfter

Confirm all four conditions:

• The Thumbprint matches what Step 2 generated.
• NotAfter shows a future expiry - typically five years out for Exchange self-signed certificates.
• No old thumbprint appears in the output.
• Outlook, OWA, and ActiveSync clients connect without certificate warnings.

If any client still reports a certificate error after iisreset, reopen IIS Manager and recheck Default Web Site bindings on port 443. The third-party certificate may need to be reselected manually. Certificate-related outages cost organizations between $50,000 and $250,000 per incident in 31% of cases, according to a DigiCert survey cited by Resilience Forward - a number that makes a 20-minute maintenance window look very affordable.

Microsoft's broader platform security is also worth watching as you maintain Exchange. The Windows 10 ESU extension to October 2027 affects organizations still running Exchange on Windows 10-era infrastructure, and may influence your patching timeline.