RSS Subscription 167 Posts and 2,769 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).

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

  1. on 26 Jul 2013 at 9:11 pmRick Lemon

    What is even better is to leverage an SRV record and to not use an A record or CNAME at all. This allows you to point autodiscover to an URL that is not confined to start with AUTODISCOVER. You can then kiss SAN certificates goodbye. Why purchase the expensive thing if you don't have to? For small businesses this is a significant savings.

  2. on 21 Aug 2013 at 9:45 amsat

    Thanks for this great article Elan,__I have a query on a similar situation, my exchange deployment is in mix mode with 2007 and 2010 and majority of the users are moved over to 2010 already. Everything is working fine but from a internal domain joined client when i initiate Test-EmailAutoConfiguration i see the same cert popup as you mentioned in your article above for my and it failsback and eventually connects to the Exchange system.__The question is being a internal domain joined client why it would even attempt to go to only thing different i see is the SCP sequence, since we changed the 2007 systems to use and the 2010 deployment took over the primary url's including the AutoDiscoverServiceInternalUri, and based on my research the oldest SCP object is queried first so the first SCP query goes to and because the user is on 2010 it replies with a 302 redirect to use for autodiscover. And the next SCP connection attempt goes to and clients connect successfully via SCP.__The confusion is since the above redirect is still happening on the SCP level why would the client even try the built-in connection attempts…. Any thoughts on this?__-Sat

  3. 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.

  4. 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.

  5. 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

  6. 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…

  7. on 18 Oct 2013 at 8:20 amDavid

    I think I might have this problem. Perhaps you can help confirm this. My public website is hosted by an ISP, not at my campus. We use a self signed Exchange certificate, since we have only one campus and only 200 users on Exchange. Some users get the same popups you describe, reporting that the name does not match. My subject is the exchange server name, SANs listed are the FQDN,

  8. on 26 Nov 2013 at 3:23 amMichael Firsov

    P.S. It's very strange:

    "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):

    – it means the first uri for Outlook to check must be, but Outlook does not use it in case there's no problem/no certificate on a public web site, but the it is this uri that starts causing the problem should the public web site have a certificate…???

  9. on 16 Dec 2013 at 1:56 pmjason

    Question about autodiscover when you change your primary smtp address to something other than your domain. Upper management here decided we were switching over to an .ORG instead of .COM. Our exchange 2010 SP2 environment was set up entirely on Now they had us change our primary smtp address for every user to say We have no service records internal or external, nothing on our SAN cert for, etc. We are finding even though Win7 clients can connect with OA, WinXP users can't. Not to mention this is playing havoc with outlook clients in some way or another with calendar sharing, advanced search feature, etc.
    I've read that you can add a srv record internally and externally to those zones, but then you get a warning in your outlook client when using OA about "being redirected to another site". How about just adding to the SAN cert and adding A records in both the internal and external DNS zones?
    I think if we ever upgraded to Exchange 2013 which uses OA connection method it will get even worse.

  10. on 07 Oct 2014 at 8:14 amPat

    Briliant artcle. Thanks a ton. I was pulling my hair out trying to figure this out.


  11. on 10 Dec 2014 at 12:07 pmMike

    The easiest way to go is to recreate CSR key for a certificate with the exchange management console and make sure you have all domains that you need (,, … etc)
    Exchange Management Console -> Exchange on-premises -> Server configuration -> “click on right panel – New Exchange Certificate” – follow wizard and generate CSR – send it to SSL company or reissue certificate yoursellf if you can – add certificate to exchange by following wizzard on Exchange Management Console.


  12. on 10 Dec 2014 at 12:08 pmMike

    The easiest way to go is to recreate CSR key for a certificate with the exchange management console and make sure you have all domains that you need (,, … etc)
    Exchange Management Console -> Exchange on-premises -> Server configuration -> "click on right panel – New Exchange Certificate" – follow wizard and generate CSR – send it to SSL company or reissue certificate yoursellf if you can – add certificate to exchange by following wizzard on Exchange Management Console.


  13. on 17 Dec 2014 at 11:50 amAndre

    Thank you, I’ve been banging my head against the wall for weeks trying to figure out why Autodiscover was failing for external networks.

    Is it possible that Outlook has trouble dealing with wildcard certificates too? Our site was not having any certificate errors, but was using a wildcard certificate. Outlook did not display any SSL errors during Autodiscovery but was still silently failing.

    Not being able to change anything on our public web site, I instead blocked the site “” on the client via the etc/hosts file during Outlook setup and everything suddenly worked as expected.

Trackback this post | Feed on Comments to this post

Leave a Reply