Hey,

Our public domain is domainname.com.  Our internal AD domain is corp.domainname.com.

We currently have a single, multi-role Exchange 2010 server.  Outlook clients reports the server as being servername.corp.domainname.com in Account Settings > Server Settings.

We gearing up for the SSL change from 1 November this year where internal names are no longer allowed on a certificate, and I'm not sure how best to proceed.

We have these 2 on our current SAN certificate:

servername
servername.corp.domainname.com

As well as all the 'public' facing Exchange stuff:

autodiscover.domainname.com
mail.domainname.com
webmail.domainname.com (OWA)
mobile.domainname.com (ActiveSync)

My initial thought is to have Outlook clients connect to mail.domainname.com as that's already on the certificate, instead of the internal FQDN.

But I'm not sure how to do that and if it has any repercussions elsewhere?

Thanks

• Edited by Lanky Doodle Friday, July 03, 2015 9:40 AM

Since this is Exchange 2010, provided your internal users can resolve the public name mail.domainname.com so it points to your Exchange server, and they're using the default non-Outlook Anywhere connection, they'll be just fine given that they're using RPC over TCP, hence the certificate not coming into play, just like Rhoderick mentioned. David's suggestion also needs to be implemented, since if that value is at the default (explicit server name in URL), then clients will get a warning when accessing it after the new certificate containing only public names is deployed. For outside users things will stay mostly the same, since I'm assuming they'll be using an Outlook Anywhere connection.

As for the certificate itself, you might be better off buying a wildcard one (*.domainname.com). From my experience, if you're using 3 or more explicit SAN names, it becomes cheaper to get the wildcard one.

• Proposed as answer by David Wang_Microsoft contingent staff 6 hours 3 minutes ago