OWA and ECP broken after certificate changes: fixing the Exchange Back End 444 binding

You renew or tidy up certificates on an Exchange server, everything looks fine, and then after the next reboot or IIS reset Outlook on the web and the Exchange admin center show a blank page and the Exchange Management Shell won't connect. The usual culprit is the HTTPS binding on port 444 of the Exchange Back End website. In this post I'll show how to confirm it, put the right certificate back and stop it happening again.

Symptoms#

• The OWA or ECP sign-in page loads, but after you sign in the page stays blank.
• ActiveSync devices stop receiving mail, and other proxied clients can fail too.
• The Exchange Management Shell can't connect:

New-PSSession : [ex01.contoso.com] Processing data from remote server ex01.contoso.com failed with the
following error message: The WinRM Shell client cannot process the request. The shell handle passed to
the WSMan Shell function is not valid. ...
Failed to connect to an Exchange server in the current site.
Enter the server FQDN where you want to connect.:

• The System log may show HttpEvent ID 15021: An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.
• It started after certificate work: a public certificate renewed and the old one deleted, a clean-up of "untrusted" self-signed certificates, or bindings edited in IIS Manager. It often appears days later, because IIS only notices after a restart.

Why it happens#

Every Exchange 2016, 2019 and SE server with the Mailbox role runs two IIS websites. The Default Web Site (ports 80 and 443) is the front end that clients talk to. The Exchange Back End site (ports 81 and 444) hosts the real OWA, ECP, EWS, ActiveSync and PowerShell applications. The front end authenticates the request and proxies it to port 444 on the server that holds the active copy of the user's mailbox database, which may be a different server.

Setup creates a self-signed certificate with the friendly name Microsoft Exchange and binds it to port 444. There it secures traffic between the two sites, which users never see, so it doesn't need to be publicly trusted. If that certificate is deleted, or the binding is pointed at a certificate that later disappears, HTTP.sys can't complete the TLS handshake and the front end can't proxy anything to that server. Because of cross-server proxying, users whose mailboxes are active on the broken server are affected whichever server they connect to.

How to fix it#

1. Confirm the binding is broken#

On each Mailbox server, in an elevated PowerShell window, compare what HTTP.sys has bound to 444 with the certificates in the computer store:

netsh http show sslcert ipport=0.0.0.0:444
Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint, FriendlyName, NotAfter, Subject -AutoSize

Healthy looks like a Certificate Hash that matches an unexpired certificate named Microsoft Exchange. If the binding is missing, or its hash matches nothing in the store, you've found the fault. In IIS Manager, Sites › Exchange Back End › Bindings › https (444) › Edit shows the same thing: no certificate, or the wrong one.

2. Make sure a valid Microsoft Exchange certificate exists#

If the certificate is still in the store and only the binding changed, go to step 3. Otherwise create a new one. When EMS on the broken server asks for another server FQDN, give it a healthy Exchange server and target the broken one by name:

New-ExchangeCertificate -Server EX01 -SubjectName "cn=EX01" -DomainName EX01,ex01.contoso.com -FriendlyName "Microsoft Exchange"

If you're asked whether to overwrite the existing default certificate, answer No. In a single-server organisation, open an elevated Windows PowerShell session on the server and load the snap-in just for this repair: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn.

3. Bind it to port 444#

In IIS Manager, open Sites › Exchange Back End › Bindings, edit the https binding on port 444 and select the Microsoft Exchange certificate (use View to check the thumbprint if more than one has that name). On Server Core, use the WebAdministration module instead:

Import-Module WebAdministration
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.FriendlyName -eq 'Microsoft Exchange' -and $_.NotAfter -gt (Get-Date) } |
  Sort-Object NotAfter -Descending | Select-Object -First 1
$binding = Get-WebBinding -Name 'Exchange Back End' -Protocol https -Port 444
$binding.RemoveSslCertificate()   # an error here just means nothing was bound
$binding.AddSslCertificate($cert.Thumbprint, 'My')

4. Restart IIS#

Run iisreset from an elevated prompt (expect a brief interruption on that server), then repeat steps 1–4 on every Mailbox server where the binding was wrong. While you're in IIS Manager, confirm that the Default Web Site's 443 binding still holds your CA-issued certificate.

Verify the fix#

• netsh http show sslcert ipport=0.0.0.0:444 shows the thumbprint of the valid Microsoft Exchange certificate.
• OWA and ECP load fully for a user whose database is mounted on the repaired server (Get-MailboxDatabase -Status | Format-Table Name, MountedOnServer).
• The Exchange Management Shell opens on the server without errors.
• No new events: Get-WinEvent -FilterHashtable @{LogName='System'; Id=15021; StartTime=(Get-Date).AddHours(-1)} -ErrorAction SilentlyContinue returns nothing.
• A test ActiveSync device receives a new message.

Prevent it next time#

• Before deleting any certificate, check what uses it: Get-ChildItem IIS:\SslBindings | Format-Table IPAddress, Port, Thumbprint (after Import-Module WebAdministration).
• Never remove the Microsoft Exchange self-signed certificate. It's valid for five years; renew it with Get-ExchangeCertificate -Thumbprint <old thumbprint> | New-ExchangeCertificate, bind the new one to 444 (step 3), check that 443 still has your public certificate, and only then remove the old one.
• A public certificate renewal only needs Enable-ExchangeCertificate -Services IIS for the front end; there's no reason to touch the Exchange Back End bindings (see renewing the SAN and Auth certificates).
• Run iisreset in the same maintenance window as any certificate change, so a bad binding fails while you're still watching, and review certificate lifetimes with the Health Checker.
• If OWA or ECP returns HTTP 500 and the 444 binding checks out, look at the other causes in OWA and ECP HTTP 500 errors: telling the causes apart.

References#

• Unable to open OWA, ECP, or EMS after a self-signed certificate is removed from the Exchange Back End website (Microsoft Learn)
• Fix failed Exchange Server updates: blank page in EAC or Outlook on the web (Microsoft Learn)
• Renew an Exchange Server certificate (Microsoft Learn)