4

We have an Exchange 2010 Server, running within our Active Directory domain, with an internal hostname of server.example.local.

The server is configured for Exchange anywhere, but currently has a self signed certificate with a name of server.example.local installed.

Internally, clients connect and work fine, but externally, we are having certificate errors as you would expect.

I'm about to purchase a UCC SSL Certificate to install on the server with all the relevant SANs on the certificate to correct this, but due to obvious problem obtaining a trusted cert with .local as a subject alternative name, I'm looking to configure clients on the internal network so that they don't use any reference to the .local hostname.

I've configured our external DNS name for the server as exchange.example.com, and have created an CNAME for autodiscover.example.com which also (correctly) points to exchange.example.com. I've also configured internal DNS records for these two hostnames which point to the internal interface of the same server. I don't anticipate any problems here.

I'm now trying to reconfigure Auto Discover internally, so that Outlook attempts to connect to exchange.example.com. I've followed the steps in KB940726 to prepare for this, and this appeared to work fine. No errors were generated and I was able to verify the CAS name in AD using ADSI edit.

I've just tried testing this with a newly created test user account complete with a new Exchange mailbox, and Outlook 2007 connects fine on the internal network, but looking deeper in the Exchange profile, Outlook is still resolving the server name as server.example.local.

Could it be the self signed cert, that is causing Outlook to display the server name as server.example.local, or is there still something wrong with my internal autodiscover configuration?

Edit

I've proven it isn't the certificate that is responsible for outlook returning server.example.local, by installing another self certified certificate with a name of test.example.com. When creating a new outlook profile, I get the mismatch error I'm expceting, but after accepting the cert, and finishing the config of the Outlook profile, again it still shows server.example.local as the server name. This means that if I were to purchase the UCC cert now, that external client would work fine, but internal clients would show a certificate name mismatch.

Any ideas where to start diagnosing this?

Bryan
  • 7,538
  • 15
  • 68
  • 92
  • at first blush, it looks ok. Would the outlook client simply be resolving the name of the server to the internal IP and then subbing in the DNS entry in its place? for instance, if you ping the IP of the internal server, what does the windows client think the name of the machine is? – MikeAWood Jun 08 '12 at 20:42
  • I don't believe it is getting it from DNS, as internally `exchange.example.com` is an A record pointing to the same IP that `server.example.local` points to. There is no reverse DNS record for the IP address either. `nslookup exchange.example.com` (or ping) doesn't resolve the name to `server.example.local`. – Bryan Jun 08 '12 at 20:51
  • if the machine is registering with DNS, then it will resolve to the host name. try "ping -a " and see what it says. – MikeAWood Jun 08 '12 at 20:59
  • Yes, that resolves to `server`, no mention of `example.local`, but I guess that could be implied. – Bryan Jun 08 '12 at 21:02
  • I think its just a side effect of the way Windows DNS works. But I know your focus was on the external resolution for autodiscovery. Did you add the autodiscover.domain.com to you SANs as well as an A/CNAME record for that to your external DNS? – MikeAWood Jun 08 '12 at 21:04
  • I've not yet purchased a SAN cert, that's my next step once I've proved it will work internally. I'm using the theory of 'measure twice, cut once', as I don't want to end up purchasing a cert that doesn't work internally, because of this `server.example.local` name I'm still seeing internally. – Bryan Jun 08 '12 at 21:07
  • if your machines are on the domain, they will trust the exchange servers already. You'll only need those certs for the externally resolved names. But since (as we've proved), the machine resolves to the server.example.local, you should be all set. – MikeAWood Jun 08 '12 at 21:19
  • Whilst the internal clients (which are all domain members) might well normally trust the server, it's likely that unless I include the `.local` name as a SAN on the cert, that I'll have [certificate name mismatch](http://www.microsoftnow.com/2008/04/certficate-name-mismatch-in-outlook.html) problems. I don't want to buy a cert with a `.local` SAN. I've read that requests for `.local` names are likely to be denied in the future, hence my reluctance to use one now. – Bryan Jun 08 '12 at 21:35
  • Sounds to me like your client is set to append its DNS suffix to the unqualified name it gets back from DNS, and your server is either set to register its .local connection suffix in DNS, or not register one at all. That's where I'd check first (Connection Status -> Properties -> IP Properties -> Advanced -> DNS tab) – HopelessN00b Jun 08 '12 at 21:54

1 Answers1

2

I believe I've managed to fix this using ADSI edit.

Despite me running the commands in the KB article I linked in my question, I found two autodiscover entries using ADSI edit.

  • CN=exchange.example.com
  • CN=server

I've deleted the CN=server entry, and had to make a modify the serviceBindingInformation property of the object CN=exchange.example.com to reflect the correct external URL.

Now when I set up a new exchange profile, or open outlook for an existing user, I get a certificate name mismatch error. This is expected though, as my certificate is still the self signed cert which only has the name server.example.local. I can clearly see now though that the internal clients are looking for the name exchange.example.com on the certificate.

I'm going to order the UCC certificate now, with correct SAN names of exchange.example.com and autodiscover.example.com, which I believe will now leave me with a working system.

Update

I've now ordered and installed a trusted certificate with a name of exchange.example.com, plus a SAN of autodiscover.example.com, and I can report that outlook anywhere is working great in the following scenarios

  • internally on the example.local corporate network with domain connected PCs.
  • externally with roaming domain connected laptops
  • externally with mobile devices (iPhones & iPads)
  • externally with non domain connected PCs.
  • OWA no longer gives SSL errors.
Bryan
  • 7,538
  • 15
  • 68
  • 92