Exchange: Replacing certificate for Microsoft 365 hybrid connector’s

When certificates needs to be renewed or changed on (on-premise) Exchange server’s, and you have Microsoft 365 hybrid setup though Hybrid Configuration Wizard, a Office 365 connecter is setup as send and receive:

Receive:

Send:

If you try to delete the old certificate, without setting the new cert for the connectors, you will get this in ECP:

“A special Rpc error occurs on server EXCH01: These certificates are tagged with following Send Connectors : Outbound to Office 365. Removing and replacing certificates from Send Connector would break the mail flow. If you still want to proceed then replace or remove these certificates from Send Connector and then try this command.”

So we need to move into Powershell and replace it, because it cannot be done through the ECP:

  • Get the thumprint for the new cert:
    Get-ExchangeCertificate

    So here it is, the top level cert, it’s a wildcard cert, thus the “*.” in the subject name, sorry for the maskings, this is from a non-lab environment ๐Ÿ™‚
    Copy the thumprint to notepad for next command.
  • Read the certificate subject and thumprint into a variable:
    $cert = Get-ExchangeCertificate -Thumbprint <paste the thumbprint in here from previous command>
    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)" - Do not change anything here!
  • The replace the connectors:
    Send Connector โ€“

    Set-SendConnector "Outbound to Office 365" -TlsCertificateName $tlscertificatename

    Receive Connector โ€“

    Set-ReceiveConnector "EXCH01\Default Frontend EXCH01" -TlsCertificateName $tlscertificatename

    Note: replace the word “EXCH01” with the name of your Exchangeserver like "MY-EXCH01\Default Frontend MY-EXCH01"

  • Run IISRESET

IF YOU GET: WARNING: The command completed successfully but no settings of ‘Outbound to Office 365’ have been modified.

This is because the old and new certificate have the same “issuer” and “subject”, the set-sendconnector and set-receiveconenctor, cannot thereforem tell the difference, but solution is easy:

Just add another cert on the servers thumbprint to the first script, then run all commands throgh, after that, do the same again, but now with the real cert’s thumprint, and it works ๐Ÿ™‚

Note that if you fail to replace your certificate before it expires (You forgot to), your mailflow between on-prem Excahnge and Exchange Online (365) will stop working and you will see this in the logs:

[Message=451 5.7.3 STARTTLS is required to send mail]

IMPORTANT:

You may run into “You get a blank page after logging in EAC or OWA in Exchange 2013 or Exchange 2016” or:

Read more about the fix: Exchange: An error occurred while using SSL configuration for endpoint 0.0.0.0:444 โ€“ martinsblog.dk

Source:

Replace SSL Certificate in Send Connector in Exchange Server (azure365pro.com)

 

18 Comments

  1. Kieran

    Thank you for this Martin, I spent 90 minutes this morning trying to put the issuer and subject CNs into commands as per the instructions on a similar guide, thankfully found yours before I escalated. You are a legend Sir, looking forward to reading through some of your other blog entries for helpul tips.

    Reply
    1. Martin (Post author)

      Thanks a lot Kieran! ๐Ÿ™‚

      Best regards
      Martin

      Reply
  2. R

    So I spent ages beating my head on a wall before we got ours working. If the cert you replace has the same issuer and subject name, for some reason it’s apparently not clever enough to remove the old and you end up with some hybrid of the two. Doesn’t matter that you did it by thumbprint, anyway. Mail flow never stopped working for us, but even after running the commands it still wouldn’t let me delete the old cert because it thought it was still assigned. There’s a comment on OP’s source link from someone who fixed it by temporarily assigning a random cert to the send connectors, deleting the old cert, then assigning the correct cert. You’ll lose mail flow for a few minutes but I can confirm that doing that works fine.

    Reply
    1. Martin (Post author)

      Hi, I normally assign the selv-signed cert temporarily if that happens, delete the old cert and the assign the new one ๐Ÿ™‚

      Regards Martin

      Reply
  3. Jurandir

    Unbelievable man, you’re the best.

    I’ve almost rerun Hybrid Configuration Wizard because we renewed certificate of our on premises server but conectors didnt work anymore. With Strange DNS errors. However stopped in the same day of old expired certificate.

    Thanks from Brazil!

    Your blog was saved in my Bookmarks.

    Unbelievable man, you’re the best.

    I’ve almost re-run Hybrid Configuration Wizard because we renewed certificate of our on premises server but conectors didnt work anymore. With Strange DNS errors. However stopped in the same day of old expired certificate.

    Thanks from Brazil!

    Your blog was saved in my Bookmarks.

    Reply
    1. Martin (Post author)

      Thanks for this Jurandir ๐Ÿ™‚

      Best regards Martin

      Reply
  4. David

    For anyone having issues getting the thumbprint of a new cert because the name is the same you can run this command to get the full details:

    get-exchangecertificate | format-list

    Reply
  5. George

    The last cmdlet misses an “e”: $tlscertificatenam

    Reply
    1. Martin (Post author)

      Updated, thanks for pointing it out ๐Ÿ™‚

      best regards
      Martin

      Reply
  6. Edy Werder

    Absolutely fantastic blog – Thank you

    I was able to remove an expired certificate from ECP using your Powershell commands. Good explained.

    Reply
  7. Curtis

    Could the incorrect send connector outbound to office 365 for an on-prem exchange server cause problems with the calendar for Microsoft teams?

    I’ve been investigating an issue for a company whose entire organisation has lost the calendar and the timings between a certificate being renewed and the calendar being lost seems beyond coincidence.

    Reply
    1. Martin (Post author)

      Yes maybe the OAUTH Token issue?
      Better put people with Exchange ONline license, gives the best experience for them. no matter what. But I guess there are reasons for not doing so? ๐Ÿ™‚

      Br. Martin

      Reply
  8. Jonas

    Hi Martin!

    I’m glad I found your blog. I have an issue that occured in my Exchange 2016/MS365 hybrid-environment after the SSL certificate was renewed. The consequences where the following:
    1) the mail flow stopped (no inbound mail to clients)
    2) the ECP and OWA became inaccessible.

    The first issue was corrected quickly by finding the thumbprint of the new SSL wildcard/SAN cert and fixing it like described here. Reset IIS and mailflow back on again after a matter of minutes.

    However, the access for ECP/OWA is still broken (for the accounts that still only resides on the on-prem server, I should point out. They have not been migrated yet because of various reasons).

    The issue/error is presented like this:
    The OWA and ECP sites are up and running, looking fine. But when trying to log in with verified credentials, the site only seem to “blink”/refresh.
    It is not presenting any error code, change of URL or similar.
    Logs in Windows/Exchange/IIS shows nothing that indicates an error.
    If I enter the wrong password intentionally for an account, it correctly says the password is wrong. So authentication is working, and this confuses and stressed me out, as this has been going on for a few days now.

    What I have tried the following to no avail:
    * Using multiple computers and browsers
    * Cleaning local browser caches
    * Updating the configurations for ECP/OWA Default web sites and back end sites (after finding this suggestion on another forum with similar issues)
    * Restarting services
    * Restarting server
    * Checked logs
    * Validated the Authentication settings in IIS
    * Validated bindings for the sites
    * Ran Exchange health check with nothing indicating related issues.

    I’m am totally out of ideas and both our on-prem server supplier (have updated our certificates many times over the years) and Microsoft 365-support have not figured it out and are blaming each other over this.

    If you or anyone else reading this have any suggestions or direct solutions you would be life savers.

    Many thanks in advance,

    /Jonas

    Reply
      1. Jonas

        Hi Martin!

        Yes, that was one of the first inputs I stumbled across in my search for an answer. Even though it doesn’t reflect my issue (as I am not getting a blank screen, the screen just refreshes) I looked at the suggestions and tried them out, resulting in no change :/

        Reply
        1. Martin (Post author)

          OK, what about the event logs?

          Br. Martin

          Reply
          1. Jonas

            Hi Martin!

            The logs does not contain anything remotely related to any errors that could be the result of the issue at hand, unfortunately.

            However, the problem has now been resolved. The issue was that there was a sneaky Auth certificate that had expired some 40 days ago. When we earlier replaced the third party Oauth certificate and ran the HCW (as we are in hybrid mode) it must have “locked” this already expired Auth certificate, thus blocking any login attempts for OWA/ECP.

            The solution was to create a new certificate, connect it to the right service (SMTP), restart IIS and then finally run the HCW again and voilรก!

            Thanks for taking the time and I hope this might help others with the same frustrating issue

          2. Martin (Post author)

            Thanks for the follow up Jonas – glad you got it resolved anyway:-)

            Br. Martin

Leave a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close