Microsoft Exchange 2013 shows blank ECP & OWA after changes to SSL certificates

48 Replies
This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.
EDIT
This issue is described in KB2971270 and is fixed in CU6.

I ran a couple of times in this error. After applying changes to SSL certificates (add, replace or delete a SSL certificate) and rebooting the server, the event log is flooded with events from source “HttpEvent” and event id 15021. The message says:

An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.

If you try to access the Exchange Control Panel (ECP) or Outlook Web Access (OWA), you will get a blank website. To solve this issue, open up an elevated command prompt on your Exchange 2013 server.

C:\windows\system32>netsh http show sslcert

SSL Certificate bindings:
-------------------------

    IP:port                      : 0.0.0.0:443
    Certificate Hash             : 1ec7413b4fb1782b4b40868d967161d29154fd7f
    Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
    Certificate Store Name       : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled

    IP:port                      : 0.0.0.0:444
    Certificate Hash             : a80c9de605a1525cd252c250495b459f06ed2ec1
    Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
    Certificate Store Name       : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled

    IP:port                      : 0.0.0.0:8172
    Certificate Hash             : 09093ca95154929df92f1bee395b2670a1036a06
    Application ID               : {00000000-0000-0000-0000-000000000000}
    Certificate Store Name       : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled

    IP:port                      : 127.0.0.1:443
    Certificate Hash             : 1ec7413b4fb1782b4b40868d967161d29154fd7f
    Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
    Certificate Store Name       : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled

Check the certificate hash and appliaction ID for 0.0.0.0:443, 0.0.0.0:444 and 127.0.0.1:443. You will notice, that the application ID for this three entries is the same, but the certificate hash for 0.0.0.0:444 differs from the other two entries. And that’s the point. Remove the certificate for 0.0.0.0:444.

C:\windows\system32>netsh http delete sslcert ipport=0.0.0.0:444

SSL Certificate successfully deleted

Now add it again with the correct certificate hash and application ID.

C:\windows\system32>netsh http add sslcert ipport=0.0.0.0:444 certhash=1ec7413b4fb1782b4b40868d967161d29154fd7f appid="{4dc3e181-e14b-4a21-b022-59fc669b0914}"

SSL Certificate successfully added

That’s it. Reboot the Exchange 2013 server and everything should be up and running again.

Patrick Terlisten
Follow me
Latest posts by Patrick Terlisten (see all)

48 thoughts on “Microsoft Exchange 2013 shows blank ECP & OWA after changes to SSL certificates”

  1. Ahmed Mahmoud

    thanks for the post, but in the last step u add sslcert with defined hash (which is not the same hash too) from where do u get this hash??

    Reply ↓
  4. Danny Covell

    Thank you so much. Saved me from a lot of angry people! Now I just wish Microsoft updates would stop breaking things…

    Reply ↓
  7. Hermano Queiroz

    Thank you so much! Very easy steps to follow and the exact same problem. FIXED!!!!

    Reply ↓
  13. Henk

    Thank you! Got this error after renewing certificates on 2013 and you’re answer was just what i need.

    Have a good one!

    Reply ↓
  14. Mark

    Man, this saved my weekend. Thanks so much for this guide. Any idea what triggers this error? We didn’t change any certs or install updates lately.

    Reply ↓
    1. Patrick Terlisten Post author

      Great to hear that! :) I really don‘t know why this happens. But I see this error from time to time in different deployments, but mainly after certificate changes or CUs.

      Reply ↓
  17. Chris

    Thanks! Also solved a problem that occurred for us after demoting some domain controllers. Not sure why that would have have anything to do with the cert but this save me hours of scratching my head.

    Reply ↓
  19. Bryan Miller

    Bingo! Thanks for the tip. Port 444 had no cert assigned. Was working fine for months until I did some maint and rebooted it today.

    Reply ↓
  20. ts

    Amazing fix, thank you. Although as an IT person I am fond of the full reboot where possible, ** I actaully found a simple “iisreset” was sufficient in this case **

    Reply ↓
  24. jk

    You are a hero!!!

    In our case, we renewed our certificate a month ago but had not restarted, so it was still running on the old cert. After rebooting, we lost EMS and ECP, and clients lost Outlook connection.
    The flood of evt 15021 gave us the clue.

    again, thankyouthankyouthankyou!!!

    Reply ↓
  25. Julio Perez Gomez

    Amazing Fix, Sunday 7 pm…and You the first hit and the immediate solution, thank you!!!

    Reply ↓
  27. AN

    still saving exchange administrators in covid 2020. thanks mate. saved me hours from having to uninstall and reinstall the exchange box.

    Reply ↓
  28. Mark

    Just happened to one of our Exchange Server 2016 mailbox servers on CU15 after patch Tuesday. Clearly the bug still exists, but your fix worked! Thanks!

    Reply ↓
  32. Stephen

    Thanks, Fixed my issue after a Windows Update on Server 2012r2 and Exchange 2013 cu 20 in August 2020.
    Nice and easy to understand
    Cheers

    Reply ↓
  38. Clint

    Count me in with the growing list of eternally grateful sysadmins!
    Thanks you so much for publishing this still-useful fix that saved me countless hours and lots of frustration.

    Reply ↓

Leave a Reply to Joe Cancel reply

Your email address will not be published. Required fields are marked *