Hi everyone. Need some word of wisdom here.
Been dancing around this certificate request... Seems like every time I have it figured out, there is an ambush.
We have Three multi-role Ex2010 servers in Europe (MBX, CAS, Hub) and will be adding Three multiroles in Canada, Three multiroles in USA, and Three multiroles in Asia in the near future.
I started off trying to make a cert request for all these servers, even though the Canada/USA/Asia ones don't exist yet - just want to cover the bases for the future builds.
I ran the wizard (which listed each server's FQDN), added a few more legacy FQDNs and ended up with 142 SANs. Asked our Cert Authority to give me a quote for such a cert - almost $10,000 !!! Ouch!!!
(By the way the wizard also adds short NetBIOS server names to the list of SANs, which will no longer be supported by Cert Authorities after 2014.)
So I Googled like crazy everything I could find about Ex2010 certificates and carried out the following conclusions:
1. I don't need to have the CASArray FQDN on the SAN list - scratch those out
2. Most blogs recommend to change the CAS servers' AutodiscoverServiceInternalUri and InternalUrl from the actual server FQDN to a custom name and make sure that the custom name exist in the internal DNS and points to the load balanced IP address of the CAS servers. OK, I can run something like this on each Ex2010 server:
Set-ClientAccessServer -Identity PROD1MSEXM10A -AutodiscoverServiceInternalUri https://webmail-eu.child.parent.company.com/autodiscover/autodiscover.xml Set-AutodiscoverVirtualDirectory -Identity "PROD1MSEXM10A\Autodiscover (Default Web Site)" –internalurl https://webmail-eu.child.parent.company.com/autodiscover/autodiscover.xml Set-WebServicesVirtualDirectory -Identity "PROD1MSEXM10A\EWS (Default Web Site)" -InternalUrl https://webmail-eu.child.parent.company.com/ews/exchange.asmx Set-OABVirtualDirectory -Identity "PROD1MSEXM10A\oab (Default Web Site)" -InternalUrl https://webmail-eu.child.parent.company.com/oab Set-OWAVirtualDirectory -Identity "PROD1MSEXM10A\owa (Default Web Site)" -InternalUrl https://webmail-eu.child.parent.company.com/owa Set-ECPVirtualDirectory -Identity "PROD1MSEXM10A\ecp (Default Web Site)" -InternalUrl https://webmail-eu.child.parent.company.com/ecp Set-ActiveSyncVirtualDirectory -Identity "PROD1MSEXM10A\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://webmail-eu.child.parent.company.com/Microsoft-Server-ActiveSync
3. Most blogs also say that I really don't need the actual FQDNs of the CAS servers in the SAN list. Great! I can basically cover most bases by making sure that I have this on the SAN list: webmail-eu.child.parent.company.com.
My SAN list starts to look even shorter without the servers' own FQDNs. Awesome!
But then this crosses my mind - These Ex2010 multirole servers are also Hub Transports! And each one has the Default Receive Connector. And the Default Receive Connector is set up to use the actual server's FQDN. And TLS is pretty much mandatory (I know we can disable TLS on Ex2010 hub transports, but we probably won't go there).
So in order for the TLS SMTP connection among the Hub Transports to succeed, the Default Receive Connector's FQDN has to be shown on the certificate, right? So it looks like my celebration above was premature? We can't get rid of the server FQDNs on the SAN list after all?
It doesn't look like changing the Default Receive Connector's FQDN is a viable option.
Should I just retain the self-signed certs for the SMTP service and use the commercial cert for the rest of the services?
Thanks for any advice!