• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3387
  • Last Modified:

How to resolve Outlook certificate error when using single-site certifiate?

We have a client with an SBS11 server which has IIS and Exchange secured by a single-site certificate for mail.domain.com, purchased from rapidssl.com.  When configuring Outlook on remote clients, we get an error for autodiscover.domain.com which says "the name on the security certificate is invalid or does not match the name of the site".  (Local clients connect to Exchange without any certificate errors in Outlook.)

I've followed the instructions at this site to update all of the URLs to match the certificate name, but that had no effect.  http://blogs.technet.com/b/danielkenyon-smith/archive/2010/05/13/the-name-on-the-certificate-is-invalid-or-does-not-match-the-name-of-the-site-part-2.aspx

The client would prefer to use a single-site cert as opposed to a SAN cert for cost reasons.  (Under $50/year as opposed to $150-$200/year.)  This isn't a deal breaker as everything works, we would just prefer that the users not have to click Yes to the certificate error every time they start Outlook.  

I've attached the results of running the command "Get-ClientAccessServer -Identity SERVERNAME | FL".

Thanks!
Get-ClientAccessServer-Identity.txt
0
SINC_dmack
Asked:
SINC_dmack
  • 12
  • 4
  • 3
  • +1
1 Solution
 
SINC_dmackAuthor Commented:
Some more info: we are using Outlook's Auto Account Setup to configure Outlook on the remote clients.  (We have an autodiscover SRV record set up in DNS.)  If we attempt to configure Outlook manually on the remote clients, it will not connect, despite using the same settings that Outlook creates when it connects using Auto Account Setup.  

Interestingly, Outlook Autodiscover RPC-HTTP passes when tested on www.testexchangeconnectivity.com, regardless of whether we let the test autodiscover or manually specify the server settings.
0
 
Pete LongTechnical ConsultantCommented:
>>Remote Clients

Are you using Outlook anywhere? SBS has an annoying habit of setting the FQDN of Outlook anywhere to remote.domainname.com, and gives loads of cert errors because the name does not match the cert - even though its the right cert

http://technet.microsoft.com/en-us/library/aa996902(v=exchg.141).aspx
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
SINC_dmackAuthor Commented:
Hi Pete,

Thanks for the reply.

I had already run the following commands as part of the recommendations from here: http://blogs.technet.com/b/danielkenyon-smith/archive/2010/05/13/the-name-on-the-certificate-is-invalid-or-does-not-match-the-name-of-the-site-part-2.aspx

Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUri https://mail.publicdomain.co.uk/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity "EXCHANGE-MAIL\EWS (Default Web Site)" –InternalUrl https://mail.publicdomain.co.uk/EWS/Exchange.asmx

Set-OABVirtualDirectory -Identity “EXCHANGE-MAIL\OAB (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/OAB

Set-ActiveSyncVirtualDirectory -Identity “EXCHANGE-MAIL\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/Microsoft-Server-Activesync


I added the following command, but it had no effect.  (I even rebooted the server just for the heck of it.)

Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAIL\EWS (Default Web Site)’ –ExternalUrl https://mail.publicdomain.co.uk/ews/exchange.asmx
0
 
SINC_dmackAuthor Commented:
Hi Pete,

Yes, we are using Outlook Anywhere.  The external host name for Outlook Anywhere is set to mail.domain.com.  (I just verified this.)
0
 
Pete LongTechnical ConsultantCommented:
On a 'problem client' if you remove the mail profile and recreate it does the problem persist?
0
 
SINC_dmackAuthor Commented:
Yes.  This is a freshly installed SBS11 box, and we've tried deleting and recreating Outlook profiles with no change.
0
 
Simon Butler (Sembee)ConsultantCommented:
Was the server setup using the wizards in SBS? SBS configures itself automatically to use a single name SSL certificate, so if the wizards were used then internally everything is configured correctly for you - no need to change things manually.

Externally you need to use SRV records in your DNS.

You also need to look around some more at SSL certificates. You can get UC/SAN certificates for a lot less than US$200 - US$60/year is easily found.

Simon.
0
 
SINC_dmackAuthor Commented:
R-R, I went to www.cohesivelogic.com and entered all of the commands (even though some of them were repeats of commands previously entered).  Everything entered correctly and when I ran the commands to verify, everything was correct.  However, when I connected to the Exchange server from a remote client, I still got the certificate error.

I also verified the rest of the steps listed on that site:
--external DNS for mail.domain.com is pointed to the external IP
--an SRV record for _autodiscover._tcp.domain.com is in place and tests successfully (clients can connect via autodiscover)
--internal DNS for mail.domain.com is pointed to the mail server's internal IP address
--Outlook RPC-HTTP tests successfully at testexchangeconnectivity.com using autodiscover or manually entering the mail server settings
0
 
SINC_dmackAuthor Commented:
Sembee2, I didn't have the wizard do the Exchange configuration for mail.domain.com.  (The SBS initial installation of course set up Exchange to the point that it would handle internal email for mail.domain.local.)  I was unaware that there was a wizard for configuring external email in Exchange.  How do I get to the wizard in SBS11?
0
 
Simon Butler (Sembee)ConsultantCommented:
There are a series of wizards on the first panel in the SBS management console. If you complete each of them then the server is configured correctly. The internet name wizard sets both the email address and the host name. It needs to match your SSL certificate name.

Simon.
0
 
SINC_dmackAuthor Commented:
We initially set up the server without using the wizards.  I completed all of the wizards under the Connect to the Internet heading of the SBS Console.  The "Set up your Internet Address" part failed, but that was due to the default receive connector being missing.

http://blogs.technet.com/b/sbs/archive/2008/09/29/fix-my-network-wizard-fncw-fails-to-fix-the-exchange-smtp-connectors-in-sbs-2008.aspx

After recreating the default receive connector, I was able to complete that part and the "Add a Trusted Certificate" part successfully.  I followed up by testing Outlook RPC at www.testexchangeconnectivity.com, and it passed.  However, I still get a certificate error for autodiscover.domain.com shortly after starting Outlook 2010 (or earlier).
0
 
SINC_dmackAuthor Commented:
Also, worth noting is that when I did the "Set up your Internet Address" part, when prompted for my domain name, I clicked the Advanced button and substituted "mail" in place of "remote".  (My certificate is for mail.domain.com.)
0
 
Simon Butler (Sembee)ConsultantCommented:
Crucial question - is this an Internal Outlook client or a client on the internet?
Internal clients, where the client is a member of the domain AND is inside the network don't use the autodiscover.example.com host name for Autodiscover, they use the host name that should be configured by the SBS server.

Externally they will use it, which means that with a single name SSL certificate you have to ensure that autodiscover.example.com doesn't resolve anywhere and configure SRV records for Autodiscover instead.

Simon.
0
 
SINC_dmackAuthor Commented:
Both internal and external Outlook clients are getting the certificate error for autodiscover.domain.com.  

Most of the internal clients are Outlook 2010 and older, and are not members of the domain, but some of the internal clients are Outlook 2013 and are members of the domain. The certificate error appears on all internal clients, regardless of version of Outlook or domain membership.  (Outlook 2013 fortunately has the little checkbox for "don't warn me about this certificate error again", so it's a non-issue on those boxes.)  External clients are primarily Outlook 2010.  

Both the internal and external Outlook clients have resolved the server name to internalservername.domain.local.

I don't remember if we had the internal clients autodiscover the Exchange server, or if we manually entered the server name as mail.domain.com or internalservername.  I think we've done it both ways, though, and since the certificate error affects all clients, I don't think that specifically has an effect.

External clients were all configured by using autodiscover.  

I don't follow what you mean by "ensure that autodiscover.example.com doesn't resolve anywhere and configure SRV records for Autodiscover instead".  Please elaborate.  

We have an A record for autodiscover.domain.com and an SRV record for autodiscover configured as follows:
Service - _autodiscover
Protocol - _tcp
Name - @
Priority - 0
Weight - 0
Port - 443
Target - mail.domain.com

Thanks!
0
 
Simon Butler (Sembee)ConsultantCommented:
Autodiscover isn't a one time thing. It is used constantly by Exchange.
Your problem is that you have an A record for Autodiscover and SRV records. You shouldn't have both, one or the other.

With a single name SSL certificate (which doesn't have autodiscover.example.com as one of the additional names) you shouldn't have the A record, just the SRV record. That applies for both internal and external clients.

Clients that are on the domain don't use autodiscover.example.com, unless that is the address configured in Exchange. You can see that with this command:

get-clientaccessserver | select Identity, AutodiscoverServiceInternalURI

The host name listed must resolve internally to the Exchange server and be on the SSL certificate.

Simon.
0
 
SINC_dmackAuthor Commented:
Hi Sembee, for a completely different network that was configured comparably, I removed the autodiscover.domain.com A-record from DNS at the domain control panel and from the internal DNS server, and I added an SRV record for autodiscover at the internal DNS server.  Both internal and external Outlook clients no longer display the certificate error during my initial tests.  

I'll implement the same changes for the client in question here.  It'll probably be some time next week before I'm onsite again to confirm that getting rid of the autodiscover.domain.com A-record has fixed the problem, but it does seem likely that it will.  I'll follow up once I've confirmed.  Thanks for your help!
0
 
SINC_dmackAuthor Commented:
I also ran the get-clientaccessserver command that you specified, and the response included mail.domain.com (which matches what's in the SSL certificate).  So the Exchange configuration appears to be correct as far as that's concerned.
0
 
SINC_dmackAuthor Commented:
Sembee2 was right on.  I removed the A-record for autodiscover.domain.com for two different clients' domains that were continuously throwing certificate errors, so that only the SRV record for _autodiscover was performing that service for each domain.  The certificate mismatch errors have disappeared.  I now get a one-time prompt that basically says "do you want to allow mail.domain.com to perform autodiscover for you?"--I click Allow and "don't pester me about this again", and now Outlook works both internally and externally with no further certificate errors or prompts whatsoever.  Thank you!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 12
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now