You know the one I am taking about. The self-signed certificate with a friendly name of “Microsoft Exchange” that each server issues by itself to itself. They are valid for 5 years , then suddenly, they are not. When on-premises was king, you rarely saw any questions about these. They just worked – and as companies upgraded, new ones were created on the new version servers, mailboxes were moved and the old certificates disappeared as the servers were retired.
Today, as more migrate to Exchange Online, these old 2010/2013 servers seem to be kept around longer during the migration, frozen in time and are now bumping into that 5 year certificate lifetime.
So why renew it? It doesn’t appear to be doing anything. Well Sir or Madam, that is the certificate bound to the “Exchange Back End” IIS site and essentially secures all the internal communications.

If it expires, you could start experiencing the following side effects:
Dizziness
Dry Mouth
Exchange Powershell errors
Errors in the event logs such as :

See that :444? That’s the backed port number
To fix:
NOTE: Some have mentioned in the comments below that these steps also removed the IIS service from the public SSL certificate. To fix: Once done: Reassign IIS to the public cert…In other words, the 3rd party certificate clients use to connect to Exchange…
First, simply renew the certificate. You can do this in Powershell or EAC by highlighting the “Microsoft Exchange” certificate and clicking Renew.
Second, you’ll want the server itself to trust this new self-signed certificate. Nicely enough, the original Exchange setup program does this for you. When you renew the self-signed certificate, not so much. Once that new certificate is created, open MMC and add the Certificates snap-in on that server. From there, choose the “Computer Account” and then “Local Computer”.
Copy the new certificate from Personal/Certificates to Trusted Root Certificate Authorities/Certificates. If you access the properties on the new certificate and go to the “Certification Path” tab, it should show as OK.
Third, add the new certificate to the Back-end Binding and run IISRESET.
From the article I first linked above. Do the following:
- Start IIS Manager on the Mailbox Server.
- Expand Site, highlight Exchange Back End, and select Bindings from the Actions pane in the right side column.
- Select Type https on Port 444.
- Click Edit and select the Microsoft Exchange certificate.
- From an administrator command prompt, run IISReset. ( Do this off-hours if this a standalone Exchange Server. If you are using a DAG, then move all the databases to other servers and have at it)
You’ll go from this:

To this:

You are done for another 5 years.
Absolutely perfect article, I spoke to MS twice to ensure I didn’t create an outage, sure enough their process was way off. I followed the above article and it worked perfectly. Thank you!
LikeLiked by 1 person
This is the best post i have seen in a while! After trying 20 different solutions that didn’t work, your post helped me solve the problem in 5 minutes! You, my sir, are a genius! Than you a million times!
LikeLike
Very nice article, Thanks for sharing
In my case, even after setting up the Exchagne Certificate on the Backend IIS, the Default WebSite \443 lost its certificate, so I needed to point it to the original certificate and things are working fine now
LikeLike
Thanks for the procedure. One word of warning; when I did this, it removed the IIS service from my public SSL cert and of course, because of that, was giving certificate errors when trying to log into OWA or ECP.
Quick fix by reassigning IIS to the public cert, but wanted to mention it.
LikeLike
This is a pretty serious omission. Author should fix
LikeLike
I haven’t seen this myself, but will add to the blog. Thanks!
LikeLike
This happened to me as well. I did not notice it though until I tried to migrate a mailbox to Exchange online. We are in a Hybrid Exchange deployment. Exchange on premises could not verify the MSR proxy service due to a certificate issue. Reassign IIS to my Go Daddy cert and am doing a migration now!
LikeLike
I have to give you credit, this was perfect. If only Micro$oft could spend some of their billions on similar documentation so IT people don’t have to scour the Internet for gems such as this, the world would be a lot better place.
LikeLike
Do I need to do this on every DAG member server?
LikeLike
Yes, check each server!
LikeLike
Fantastic!! Thank you so very much for writing this up. Saved me so much time 🙂
LikeLike
I wish there was a way to update the backend certificate through powershell. This can only be completed remotely if the Exchange server is running on server core.
LikeLike