On every Exchange server you need SSL certificates for authentication, validation and encryption purposes. For SMTP you can use the self-signed certificate. Exchange 2010 uses opportunistic TLS, so the self-signed certificate will do in this scenario. If you need to configure domain security (mutual TLS) on Exchange, you need a proper 3rd party SSL certificate for this.
SMTP communication between Office 365 and Exchange in a hybrid scenario is an example of mutual TLS or domain security. A proper 3rd party SSL certificate is needed on your Exchange server.
I was always under the impression that mutual TLS can only use the Common Name of the certificate, which in my scenario is CN=webmail.inframan.nl. After a previous blogpost there was an interesting discussion (see the comments of this particular blogpost) about this, so now it’s time to do some testing.
Originally I had a Digicert SSL certificate with Common Name CN=webmail.inframan.nl, and a Subject Alternative Name entry autodiscover.webmail.com. During the HCW I entered webmail.inframan.nl and selected the proper certificate.
It was time to renew my SSL certificate, so I added an additional SAN entry o365mail.inframan.nl.
When running the Hybrid Configuration Wizard again on my Exchange 2010 server I select the proper SSL Certificate:
And entered the additional FQDN o365mail.inframan.nl:
When validating the connector it succeeds successfully, but when you look closely it still uses the old FQDN webmail.inframan.nl.
I would expect the new FQDN here, but apparently the HCW does not reconfigure the Office 365 Receive Connector on my Exchange 2010. It still is configured for webmail.inframan.nl:
So, after changing it to o365mail.inframan.nl:
The validation process again succeeds successfully, but now uses the o365mail.inframan.nl FQDN (and SAN entry on the SSL certificate) for mail flow from Office 365 to Exchange 2010:
So, in contrast to my previous belief you don’t need a separate SSL certificate for an additional FQDN but you can also use an additional SAN entry on your existing SSL certificate.
More information regarding certificate requirements for hybrid deployments can be found here: https://technet.microsoft.com/en-us/library/hh563848(v=exchg.141)
Why do you want to use this in the first place?
When using one or two Exchange 2010 servers it doesn’t make sense, but I also have a customer that has 28 Exchange 2010 servers running with 40,000 mailboxes, and here we want to separate Office 365 SMTP traffic from regular SMTP traffic. When looking at the certificates it’s easier to maintain only one SSL certificate with an additional SAN entry then an additional SSL certificate with just one domain name.
Special thanks to ‘Trekveer Harry’ for pointing me in this direction
Your welcome 🙂
Nothing is more beautifull than sharing knowledge as you do by your great blogs.
LikeLike
Hi,
Our certificate changed from Geo Trust to Digital certificate. Currently exchange 2010 configured with hybrid. Please let us know whether we need to rerun HCW when we renew certificate
LikeLike
This is no reason to run HCW again, but it’s recommended to run it on a regular basis.
LikeLike
Hi Jaap, brilliant guides simple to understand, however from this step onwards I cannot find any article on how to completely transfer mailboxes to office 365 from 2010, could you please comment. Thanks
LikeLike
Well, it’s not very different than every other Exchange migration, but it depends on how you want to migrate…. have you seen my two blog posts about Exchange 2010 hybrid?
LikeLike
Hi Jaap,
Exchange 2010 configured with hybrid and all the mailboxes are in O365. Now time to set up Ex2016 for SMTP Relay and Management.
Ex2010 Server only have Self-Signed cert.
When i rerun HCW, will that require the SSL? or can i use the current self-signed?
TA
LikeLike
For SMTP you can use the self-signed certificate, this can be configured during HCW configuration.
LikeLike
HCW8078 – Migration Endpoint could not be created
Error details: There was no endpoint listening at https://webmail.domain.com/EWS/mrsproxy.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. –> Unable to connect to the remote server –> No connection could be made because the target machine actively refused it 202.183.94.21:443
LikeLike