RSS Subscription 167 Posts and 2,643 Comments

Outlook Certificate Error and Autodiscover.Domain.Com Not Working?

I have a blog post on Outlook Certificate Errors which applies to Outlook 2007, Outlook 2010, and Outlook 2013.  You can see that post here. That blog post describes an incorrect certificate on Exchange itself.  For example, you make a connection to Exchange and your InternalURLs, ExternalURLs, and AutodiscoverServiceInternalURI FQDN is not defined on the certificate.  Therefore, you must update the InternalURLs, ExternalURLs, and AutodiscoverServiceInternalURI to match the certificate FQDN.

This specific issue is a bit different.  This issue is that when you are trying to make a connection to Autodiscover via, the Outlook client does not successfully make a connection to it and you get a certificate error.  The certificate you see pop up in Outlook during the error isn’t even the certificate that is located on Exchange.  The certificate error that pops up shows you that it is finding the certificate on your company’s public website.

So the million dollar question? Why the error and why is it showing the company’s public website’s certificate.

Well first, let’s explore a little on the steps External Autodiscover goes through in order to find Exchange.

Internal Autodiscover and the Service Connection Point

The Autodiscover service is a mechanism that can do several things.

  • Automatic Mailbox Creation
  • Redirects Outlook 2007/2010/2013 clients to point to the correct server in which their mailbox is located
  • Provides URLs to Web Services for Outlook 2007/2010/2013

When you first launch your Outlook client (Outlook 2007 or above required for Autodiscover access), it will search Active Directory for a Service Connection Point (SCP) record.  Every time a CAS Server is installed, it will register this SCP record within Active Directory in the following location:

CN=Autodiscover,CN=Protocols,CN=<CASServer>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services

When an Outlook client has the ability to find this record because they are domain joined and on the internal network, they will locate all SCP records and will choose the oldest SCP.  If you have slow links or want to scope what SCPs are available to users in various sites, Autodiscover Site Affinity can be used.  This SCP will return the AutodiscoverInternalURI FQDN in which this client should contact the Autodiscover service.  You can modify this FQDN by using the following command:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri

By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN).


It is a best practice not to use server FQDNs or NetBIOS names on a cert. So please be sure to update all InternalURLs, ExternalURLs, and the AutodiscoverServiceInternalURI to use an FQDN other than the server FQDN and other than the NetBIOS names of the servers.

So an example of how this works for domain joined clients who have access to Active Directory is included on the Autodiscover Whitepaper:

A domain joined Outlook client (again, only Outlook 2007 or above clients use Autodiscover) will find this SCP record which will return the AutodiscoverInternalServiceURI you specify with Set-ClientAccessServer.  Again, don’t forget that it’ll get a list of all SCPs for all CAS servers in your environment and use one at random.  If you have slow links or just want to force Outlook clients to use a CAS in their own site, check out my article here.

External Autodiscover Access

So we now understand how we access the Autodiscover service when we are domain joined and internal to the network.  What happens if we are on the corporate network and are not domain joined or we are external to the network and don’t have AD connectivity?  Or what happens if we connect via Outlook Anywhere when internal or external to the network? Essentially, what happens when we don’t have access to Active Directory?

Because our Outlook clients don’t have access to Active Directory, we cannot obtain the AutodiscoverServiceinternalURI since the client can’t get to the SCP record.  Because of this, Outlook will fall back to utilizing a different method.  The first method is to contact the following DNS records in order (domain = the user’s primary SMTP domain):

Every client I’ve ever worked with leverages and does not rely on  Taking a close look at the URLs, we will utilize https.  This means that we will need the name in our certificate.  To have multiple names in our certificate, we will need a Unified Communications Certificate that is provided by various vendors.

So let’s say we want our NetBIOS name on our certificate, FQDN of CAS, our OWA FQDN, and our Autodiscover name, we’d have the following FQDNs on our certificate.


So an example of how this works for domain joined clients who don’t have access to Active Directory, Outlook Anywhere clients, or non-domain joined clients is included on the Autodiscover Whitepaper:

As you can see, Outlook attempts to connect to Active Directory to get a list of all the SCPs and it fails.  Because of this, Outlook then attempts to contact  There would need to be an A record for autodiscover which will lead the client to a CAS server.  But, as I mentioned, you’re not getting this far.

What’s the Issue?

As I mentioned, the issue is that when you attempt External Autodiscover, you get a certificate error and see your Public Website’s Certificate, not the Exchange Certificate.  Why is it hitting my Public Company’s website?

When I am creating a new Outlook Profile, that is one point when Autodiscover will be contacted.


When you are in the process of Searching for your e-mail settings (aka utilizing Autodiscover), you see a certificate error as follows:


If you click View Certificate, you will see your public website’s certificate.


In the “External Autodiscover Access” section, I mentioned that is attempted before may be going to your Public Facing website.  This isn’t generally a problem.  Outlook will detect that is not Exchange and Outlook will still fallback to and then eventually connect to Exchange.

However, if your site is having a certificate error even in a Web Browser, Outlook will prompt you with the certificate error and the fallback process to will fail.  Your public facing website is most likely, but the website has been set up to allow for, and SSL is activated on  But, your public facing website only has the name on the cert.  It does not have on the certificate.  It is this reason that going to will cause a certificate error in a web browser or in Outlook.

There are one of two fixes for this:

  • Add the to your Public Facing Website’s certificate.  That way, Outlook makes a successful connection to, determines it’s not Exchange, and will fallback to attempting autodiscover via  (Preferred Option for obvious secure reason)
  • Disable SSL on the public facing website’s root.  That way, no cert error would ever happen and Outlook will happily fallback to using (Less Preferred Option for obvious secure reasons.  Be absolutely sure you do not require any kind of encrypted security on your website if you go this route).

4 Responses to “Outlook Certificate Error and Autodiscover.Domain.Com Not Working?”

  1. on 27 Aug 2013 at 8:23 amGerod Serafin

    This post says in a couple of places that the CAS server that will be chosen will be "random". That is incorrect. It is not random. Outlook will use the oldest SCP record based on creation date.

  2. on 27 Aug 2013 at 8:38 amElan Shudnow

    Yep, my mistake. I knew that but copied this from another really old Autodiscover article I wrote before I learned about the oldest SCP thing. Thanks for pointing it out, I will get it corrected.

  3. on 01 Oct 2013 at 9:56 pmlennon @ web host

    don't know if I'm happy disabling SSL. I wouldn't suggest that as a fix

  4. on 01 Oct 2013 at 10:05 pmElan Shudnow

    This article has absolutely nothing to do with disabling SSL for any Exchange related stuff and is about disabling SSL at the root only as an option. Obviously if you require any security at the root such as for logging in or anything else, you would want SSL. And if you do want SSL, make sure the certificate includes the root domain name. Both are options. Obviously you need to make the smart decision based on your needs. But again, it's still a workable option. And quite honestly, if you decide to choose the disable SSL option and your root webpage needs SSL for secure transactions or for secure logins, you shouldn't be in IT…

Trackback this post | Feed on Comments to this post

Leave a Reply