0

We have a client with an external domain of abc.com and an internal domain of xyz.local. I see a lot of articles stating that for Exchange you should have a multi-domain cert that has Subject Alternate Names for both the external and internal domains. However, we have a couple clients that have only the external name covered in the certificate and it seems to be working fine. They aren't receiving SSL error messages in Outlook or when accessing OWA. Can anyone explain why a cert that covers both the external and internal domain name would be necessary? Are there circumstances where someone could skip the internal domain without consequence?

As pointed out in the comments I could have phrased my question better. Can someone give any good reasons to have a cert that covers both internal and external domain names? This is suggested by this DigiCert article: http://www.digicert.com/ssl-support/exchange-2010-san-names.htm I've also seen Microsoft TechNet articles say something similar.

skinneejoe
  • 274
  • 1
    Can anyone explain why a cert that covers both the external and internal domain name would be necessary? - You've answered your own question. You have clients that have certificates for the external name only that work without issue, so it should be fairly obvious that a SAN certificate isn't necessary. Are there circumstances where someone could skip the internal domain without consequence? - Again, you've answered your own question. You have clients that have certificates for the external name only that work without issue. Try rephrasing your question as to why? one or the other. – joeqwerty Jul 09 '14 at 19:50
  • 3
    In short: Q: Is a Multiple Domain SSL Cert necessary for Exchange? A: No. – joeqwerty Jul 09 '14 at 19:50

2 Answers2

0

The name you use in the connection to the server is the one which is used for validating the certificate and this need to be included there. But, which name you use for connecting depends on your setup: it might be an internal name only, but it might also be the external name in case you have a split-DNS, i.e. different IP for the same hostname when resolving from inside or outside.

Steffen Ullrich
  • 13,717
0

Really this should be Joe's, as his comment is basically the answer...but to bring it home I guess:

Can someone give any good reasons to have a cert that covers both internal and external domain names?

Most shops that run Exchange do so for their own employees. As such employees often work on their computers on the internal LAN that the Exchange server(s) are on, and resolve these server's to internal DNS names.

At the same time, such employees use smart phones, work from home, work during traveling, etc. and need accessibility via ActiveSync, Outlook Anywhere, OWA to use the Exchange servers "services". Thus requiring resolution to EXTERNAL DNS names.

Typically internal and external domain names aren't the same (both in regards to hostname and domain name).

TheCleaner
  • 32,822
  • When using Outlook on a LAN it connects to Exchange using the internal DNS via TCP not HTTPS, so wouldn't that mitigate the need for an SSL cert? The only time I know that Outlook connects to Exchange using HTTPS is when using Outlook Anywhere, and then it typically is set up to query the external DNS. – skinneejoe Jul 09 '14 at 21:18
  • Outlook still uses autodiscover internally to determine the right CAS to connect to. And smartphones, etc. that are on the wireless LAN will still use Activesync. OAB and EWS also rely on the URLs. – TheCleaner Jul 09 '14 at 21:47
  • Got it, so I found an article that outlines changing the autodiscover, EWS, and OAB urls to use the external domain instead of the internal. I assume if this was done then Outlook would rely solely on external DNS and internal DNS could be safely ignored on the SSL Cert? According to the following article it seems to me that is what Cert Authorities are recommending these days: http://www.digicert.com/internal-names.htm – skinneejoe Jul 09 '14 at 22:00
  • That article refers to non-recommended internal only names. Your internal FQDN shouldn't be .local or similar anyway, see here: http://serverfault.com/questions/76715/windows-ad-domain-naming-recommendations -- But yes, if you have the ability to loop out and back into the external URL from inside your corp LAN ...OR you are willing to use split-DNS and keep the same internal and external FQDNs, then you can work around it. But my answer was based on what is recommended by MS for businesses running on-prem Exchange. – TheCleaner Jul 10 '14 at 13:54