Why is Outlook 2007 throwing an Autodiscover certificate error when connecting to SBS 2011 Exchange?
The current situation is probably the product of cumulative errors over a couple of years, but it’s reached a point where I'm pulling out what hair I have left.
An SBS 2011 Exchange installation which has been working fine for years has recently started throwing an autodiscover name mismatch certificate error when Outlook 2007 is started on a domain computer. There is a website for the domain (let’s call it xyz.co.uk) although it’s not active at the moment, but the mail server at remote.xyz.co.uk is fairly busy, and it’s that name that I'm expecting to see on the SSL certificate; instead, I'm seeing the certificate for the domain name host, with the name *.123-secure.com on it although I'm pretty sure that if things were working properly I wouldn't see anything relating to SSL certificates at all.
If it’s relevant, the mail server is using a UCC SSL certificate from GoDaddy.
I've tried adding a CNAME record to the internal DNS forward lookup zone to no avail, and an SRV record for xyz.co.uk to the external DNS via the 123-reg control panel, but the error persists. I started to add a SRV record to the internal DNS forward lookup zone as well, until I noticed that the domain field at the top of the form contained remote.xyz.co.uk and not just xyz.co.uk. I sensed that pointing the record to itself might not be helpful...
Nslookup returns the IP address of the domain name host and not the static public IP of the SBS server; it lists no aliases.
The MS Test Connectivity tool for autodiscover for both ActiveSync and Outlook passes with warnings, to the effect that the DNS SRV redirect method was the only one that worked. The other methods returned name mismatches and wrong IP addresses. This suggests that the SRV record I added is both correct and necessary.
OWA works fine, and mail is sent and received without problems.
It seems that autodiscover is finding the root domain xyz.co.uk instead of being directed to remote.xyz.co.uk, so how can I fix this?
Why is the 123-secure certificate being invoked at all?
I’ve found 123-reg support to be glacially slow and entirely unhelpful so far.
Do I have to start again from scratch, or is the situation retrievable?
An SBS 2011 Exchange installation which has been working fine for years has recently started throwing an autodiscover name mismatch certificate error when Outlook 2007 is started on a domain computer. There is a website for the domain (let’s call it xyz.co.uk) although it’s not active at the moment, but the mail server at remote.xyz.co.uk is fairly busy, and it’s that name that I'm expecting to see on the SSL certificate; instead, I'm seeing the certificate for the domain name host, with the name *.123-secure.com on it although I'm pretty sure that if things were working properly I wouldn't see anything relating to SSL certificates at all.
If it’s relevant, the mail server is using a UCC SSL certificate from GoDaddy.
I've tried adding a CNAME record to the internal DNS forward lookup zone to no avail, and an SRV record for xyz.co.uk to the external DNS via the 123-reg control panel, but the error persists. I started to add a SRV record to the internal DNS forward lookup zone as well, until I noticed that the domain field at the top of the form contained remote.xyz.co.uk and not just xyz.co.uk. I sensed that pointing the record to itself might not be helpful...
Nslookup returns the IP address of the domain name host and not the static public IP of the SBS server; it lists no aliases.
The MS Test Connectivity tool for autodiscover for both ActiveSync and Outlook passes with warnings, to the effect that the DNS SRV redirect method was the only one that worked. The other methods returned name mismatches and wrong IP addresses. This suggests that the SRV record I added is both correct and necessary.
OWA works fine, and mail is sent and received without problems.
It seems that autodiscover is finding the root domain xyz.co.uk instead of being directed to remote.xyz.co.uk, so how can I fix this?
Why is the 123-secure certificate being invoked at all?
I’ve found 123-reg support to be glacially slow and entirely unhelpful so far.
Do I have to start again from scratch, or is the situation retrievable?
Cris Hanna
I would probably as Godaddy about a rekey of the cert
ASKER
I've spoken to GoDaddy about the issue and they say that the certificate is working as it should.
The problem, as far as I can see, is not the GoDaddy certificate but rather the 123-secure certificate, which has nothing to do with GoDaddy or the mail server and so is producing the error.
The problem, as far as I can see, is not the GoDaddy certificate but rather the 123-secure certificate, which has nothing to do with GoDaddy or the mail server and so is producing the error.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, progress of a sort, anyway...
Creating a new forward lookup zone for xyz.co.uk and adding the A records as described in your article has now changed the certificate name mismatch error from *.123-secure.com to remote.xyz.co.uk when starting Outlook.
This suggests that following the remaining steps in the article and adding the autodiscover.xyz.co.uk as a SAN to the certificate would resolve the issue. However, I see a possible problem here. The Exchange 2010 server is part of an SBS 2011 installation, and the latter seems to expect only a single SSL certificate which covers all the SBS remote services - OWA, OAB, RWW, etc. This particular SBS 2011 installation is using a UCC SSL certificate that has three SANs in use out of a possible five. Neither of these two other SANs have been implicated in the certificate errors, but I'm thinking that their addition to the UCC certificate a few months ago may have coincided with the start of this issue.
As neither of these SANs are in active use at the moment, would it be better to revoke the UCC certificate (which only has a few months to run) and just obtain a standard single-name SSL certificate for remote.xyz.co.uk instead? If I did this, would it resolve the Outlook autodiscover certificate name mismatch?
SBS 2011 must have a mechanism for dealing with domain Outlook clients' connection requests, as this installation worked fine until the extra SANs were added to the UCC certificate.
Creating a new forward lookup zone for xyz.co.uk and adding the A records as described in your article has now changed the certificate name mismatch error from *.123-secure.com to remote.xyz.co.uk when starting Outlook.
This suggests that following the remaining steps in the article and adding the autodiscover.xyz.co.uk as a SAN to the certificate would resolve the issue. However, I see a possible problem here. The Exchange 2010 server is part of an SBS 2011 installation, and the latter seems to expect only a single SSL certificate which covers all the SBS remote services - OWA, OAB, RWW, etc. This particular SBS 2011 installation is using a UCC SSL certificate that has three SANs in use out of a possible five. Neither of these two other SANs have been implicated in the certificate errors, but I'm thinking that their addition to the UCC certificate a few months ago may have coincided with the start of this issue.
As neither of these SANs are in active use at the moment, would it be better to revoke the UCC certificate (which only has a few months to run) and just obtain a standard single-name SSL certificate for remote.xyz.co.uk instead? If I did this, would it resolve the Outlook autodiscover certificate name mismatch?
SBS 2011 must have a mechanism for dealing with domain Outlook clients' connection requests, as this installation worked fine until the extra SANs were added to the UCC certificate.
You need to have 2 names at-least (i.e. autodiscover.email.domain.
ASKER
Apologies for the delay in my response - I became unexpectedly busy for a while.
The vast majority of the solution was provided by MAS and his article, which helped me realise what had gone wrong in the past and confirmed the need for the certificate to be rekeyed with correct data. The certificate import had to be done using the SBS 2011 wizard because it's, er, an SBS 2011 installation but otherwise the information given by MAS was spot on, so he gets the points. I know that Cris Hanna suggested rekeying the certificate, but the MAS article enabled me to understand why, and knowing the reasons behind a particular recommendation is important to me.
If this is unacceptable then please complain!
The vast majority of the solution was provided by MAS and his article, which helped me realise what had gone wrong in the past and confirmed the need for the certificate to be rekeyed with correct data. The certificate import had to be done using the SBS 2011 wizard because it's, er, an SBS 2011 installation but otherwise the information given by MAS was spot on, so he gets the points. I know that Cris Hanna suggested rekeying the certificate, but the MAS article enabled me to understand why, and knowing the reasons behind a particular recommendation is important to me.
If this is unacceptable then please complain!