Exchange 2010 FAQ: Do I Need Autodiscover Names in the SSL Certificate?

Question: Do I need to include the Autodiscover names for all of my domain names in my SSL certificate?

I’ve had a few questions lately about Autodiscover and Exchange 2010 SSL certificates. The questions are usually along the lines of:

  • Do I need to add the Autodiscover name to my SSL certificate?
  • Do I need an Autodiscover name for all of my SMTP domains in my SSL certificate?

Both questions can be answered easily once you understand the basics of Autodiscover.

Put simply, Autodiscover is a service hosted on Client Access servers that Outlook 2007 and 2010 clients can use to automatically discover information about the Exchange environment.

An example of Autodiscover in action is when a mailbox-enabled user launches Outlook 2007/2010 for the first time and the Outlook profile is automatically configured with the correct Exchange server name for that mailbox user.

For internal, domain-joined clients this involves looking up the Autodiscover SCP (Service Connection Point) for the AD Site that the user’s computer is in. Or if no SCP exists for that site the SCP in another site will be used. This is configurable and is known as Autodiscover site scope.

The SCP is returned as a URL. This URL will be one of the Client Access servers in the organization, and will look something like this:

Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri

Name                           : ESP-HO-EX2010A
AutoDiscoverServiceInternalUri : https://esp-ho-ex2010a.exchangeserverpro.net/Autodiscover/Autodiscover.xml

So for an internal, domain-joined computer the SSL certificate must include the name (or names, if more than one exists) for the Client Access servers in the organization that a client will be discovering via that SCP lookup.

Externally connected clients are different, because they can’t lookup the SCP in Active Directory from outside of the network. These clients might be roaming laptop users with Outlook, or they might be ActiveSync capable smartphones such as iPhones. In either case they will attempt to connect to Autodiscover by performing a DNS lookup for “autodiscover.smtpdomainname”.

For example an iPhone user setting up their Exchange mailbox will enter their email address (eg john@exchangeserverpro.net), user name and password. The iPhone will then attempt to autodiscover the Exchange server by looking up “autodiscover.exchangeserverpro.net” in DNS. If it can resolve that name it will then connect to https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml to retrieve Exchange server information.

So for an externally connected client the SSL certificate must include the autodiscover.exchangeserverpro.net name, or optionally the “exchangeserverpro.net” name if you don’t configure an “autodiscover” name (though I recommend you do, as often the domain name on its own resolves to a different IP address such as the web server that hosts the company’s website). Naturally that name must also be in your public DNS zone.

Now that you can see that you need the “autodiscover.smtpdomainname” name in the Exchange 2010 SSL certificate the final question is whether you need to include autodiscover names for all of your SMTP domain names.

The answer is that you will only need an autodiscover name for each SMTP domain that a user is likely to enter as their email address (eg in the iPhone example above). So for most organizations this means any domain names that are used as primary email addresses for mailboxes. Any additional domains that may be legacy names from a previous company name or a merger can probably be left out of the certificate.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Find Paul on Twitter, LinkedIn or Google+, or get in touch for consulting/support engagements.

Comments

  1. There is also a way to avoid using autodiscover in the URL by using a DNS SRV record to point autodiscover to a domain of your choosing. I do this all the time and it works great. However, though it works with Outlook 2007 and later well, various ActiveSync devices don’t seem to be smart enough to use this method and still require the server name to be entered manually (sadly, since this would be so easy to support!). It’s a great tip where you want to avoid the expense of a SAN certificate in favor of a single name cert (which also requires correct split DNS and the running of a script like this one on the Exchange server to properly set internal/external URLs–but it’s easy and works!).

  2. Andrew DeVries says:

    You can also avoid a ssl for each domain by creating a http website on teh exchange server with a binding for each domain like autodiscover.domain1.com and autodiscover.domain2.com then set a redirect to https://autodiscover.maindomain.com/Autodiscover

    • How does it help to have HTTP sites configured when clients make their Autodiscover requests over HTTPS?

      • Just thought I would add to this incase anyone comes across it. I think the guy was talking about the HTTP redirection method. Autodiscover will try HTTPS first and if it fails to locate on HTTPS will check HTTP for a redirect. If you use https://www.testexchangeconnectivity.com/ and perform the autodiscover test it will show that it tries autodiscover URLs on HTTPS and then performs a redirect check on HTTP. We had to implement the HTTP redirect method here as we have lots of domains and plan more so it didn’t make sense to keep buying SSL certs. Then if someone enters their email as b@domain.com or c@domain.com they get redirected to the main server which lives at a@domain.com

  3. Dear Paul,

    I am confused on how OL2K7+ Ext Client can get Exchange Servers information when configure OA (RPC-Over HTTPS) for the OL2K7+ profile as we provide the below details:

    1- Server Name: :
    (Is this the CAS Server/CASArray internally FQDN or Exchange MB server)
    2- Exchange Proxy Settings>Connections Settings>Use this URL to connect to my proxy server for
    Exchange: Mail.MyExDomain.com
    (Why we need this URL as OL2K7+ will check https://Autodiscover./Autodiscover
    /Autodiscover.xml to get the SCP which will provide Exchange servers details)
    Please correct me:
    O2K7+ >Autodiscover.MyExDomain.Autodiscover/Auto….xml>CAS Srv/or CAS Array>SCP>User Connect to its Exchange DB

  4. Paul,

    One thing about the internal uri, Within a CASArray where we have load balancing between 2 CAS servers, should the internal URI change on each CAS server from the http://(hostname).mydomain.local… to http://(casarrayhostname).mydomain.local?

    Also, this doesn’t need to be changed to match the external host address correct? It’s strictly internal correct as listed? I’m asking this because of external devices. Exchange only looks to this for internal clients correct? For external devices where does it find the external address within exchange. For instance where would I list autodiscover.mydomain.org as opposed to the internal uri autodiscover.mydomain.local?

    • Let me rephrase my last question. I’m not a very good proofreader. =P

      I found under the EMC the ActiveSyncVirtualDirectory internal and external URLs for activesync. So i guess my question is similar to the InternalURI. Is there an autodisocver ExternalURI required?

  5. When I am trying to use Outlook anywhere I get all 3 security alerts however I have a certificate from third party and its working fine for OWA. So when I look at the certificate on outlook from outside of the domain it show that issued to localhost.localdomain, I was wondering if this is related to autodiscover ?

    Thanks in advance

  6. I did and I got some errors, and from the outlook I test the connectivity it found the server and the autodiscover, but security alerts pop up. And the cert that outlook is using is expired so I am thinking I have to import the cert on the client maybe ?

    • No you’ll need to investigate and fix the errors that the connectivity test tool identified.

      Outlook Anywhere is much more sensitive to certificate problems than OWA.

      • But, the client report that whenever they login as domain\username they dont get any prompt but when they login as user@domain.com they get security alert.

        • Ok, so keep in mind that you know more about this case than me because I can’t see all the information end users are reporting and other details like that.

          What I’m recommending as a starting point is that you’ve got an Outlook Anywhere problem, and the connectivity test tool is giving errors for the Outlook Anywhere test, so you should start investigating and resolving those errors.

  7. Pooria says:

    I will work on those today, thank you for the time and appreciate for your great articles.

  8. Hi Paul,

    What if you use a SAN certificate and just wildcard the domain like “*.MyCompany.com”, BPA complains because it is a Certificate SAN mismatch but its not “technically” because it covers all sub-domains….but should it impact client connections? I’m currently running one and it seems work ok with activeSync and Outlook clients

  9. Jack Cristi says:

    Hi Sir Paul,

    Please help me on this, it’s been 2 days configuring the autodiscover feature of exchange server 2013…

    When i run Remote Connectovity Analyzer, it said: Connectivity Test Failed.

    Attempting to test potential Autodiscover URL https://company.net/AutoDiscover/AutoDiscover.xml
    >>>Testing of this potential Autodiscover URL failed.

    Attempting to test potential Autodiscover URL https://autodiscover.company.net/AutoDiscover/AutoDiscover.xml
    >>>Testing of this potential Autodiscover URL failed.

    Attempting to contact the Autodiscover service using the DNS SRV redirect method.
    The Microsoft Connectivity Analyzer failed to contact the Autodiscover service using the DNS SRV redirect method.

    Attempting to test potential Autodiscover URL https://mail.company.net/Autodiscover/Autodiscover.xml
    >>>Testing of this potential Autodiscover URL failed.

    Thank you so much!
    Jack Cristi

    • You are leaving comments in multiple places on my site about this same issue which is not helpful. I can only answer as fast as I am able to. If you have a serious problem requiring a faster response you should contact Microsoft support.

      Now, if you are running the RCA tests and they are failing, you need to look closer at the results to see exactly *why* they are failing. Expand the “Test Steps” to see whether the test failed because of DNS name resolution, or firewall issues, or certificate issues, or something else.

  10. Carol Ostos says:

    Hey Paul, we got a problem with Autodiscover and Good Mobile, we are setting up Good for Enterprise (EWS version instead of the MAPI version). We seem to be having difficulties when adding handhelds (provisioning devices).

    Good Support recommends to create a CNAME for autodiscover.mydomain.com, we are a multi domain company with trust between domain, there is already a CNAME for autodiscover in our company namespace.com in our top domain, do you think we would need to create an alias in our child domain as well?

    Apologies if this is too silly but just dont whether it would cause problems since Autodiscover works just fine with Outlook, Out of Office, Free Busy, etc

    Thanks for your help!

    • Generally speaking you should only need autodiscover names for domains that have users with SMTP addresses that use that domain name. But I don’t know if Good behaves differently and needs other autodiscover records, eg to match UPNs. I guess that is something their doco should cover in more clarity.

      Autodiscover can also fail due to SSL cert validity/trust issues, even when you get the DNS right.

      • Carol Ostos says:

        Thanks for your reply Paul! We realized Good for Enterprise EWS version required a minimum of Exchange 2010 SP2 RU4 so we rolled back and installed the MAPI version, no issues with that version.

        Will keep your comments in mind for when upgrading Exchange and maybe then upgrade GFE to the EWS version.

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.