• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Exchange 2010 FAQ: Do I Need Autodiscover Names in the SSL Certificate?

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

June 12, 2011 by Paul Cunningham 49 Comments

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:

1
2
3
4
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.

Exchange Server AutoDiscover, Exchange 2010, FAQ, SSL

Comments

  1. Andy says

    January 29, 2016 at 6:43 am

    Paul, can I just confirm that if my Exchange 2013 server is authoritative for two SMTP domains then I need a SAN SSL cert that has an autodiscover entry for each domain and just one entry for OA and OWA comms? And should the latter relate to the users’ UPN (apples.com)?

    autodiscover.apples.com
    autodiscover.pears.com
    webmail.apples.com

    Thank you,
    Andy.

    Reply
  2. Mridul Anand says

    January 22, 2016 at 8:43 pm

    Hi Paul,
    Thanks for the great article.
    Quick question
    If we are using split dns then where should the dns record point to Load balancer to cas array or to any of the cas servers in the site?
    I have made one ‘autodiscover’ record in the internal dns and one ‘mail’ record for the exchange services.
    I am jst confused to where should I point these dns records to?

    Regards.

    Reply
  3. Jon says

    November 7, 2015 at 12:29 am

    Hey Paul, lots of great info. I have a simple question maybe you can answer. As of November 1st all .local addresses for SSL to my knowledge were wiped. I redid my SSL with 2 SANS, I left out the autodiscover from the original cert. Everything works fine. However our website which is hosted in another state has a section where you can enter in email submissions. It doesnt send to us at all , i dont see it even hitting our filter (which is hosted). Could this have anything to do with the SSL? The company which hosts it says its working fine on their end…of course.

    Thanks
    Jon

    Reply
    • Paul Cunningham says

      November 8, 2015 at 11:13 am

      I think it’s fair for them to show you the proof that it’s working fine on their end. They should have some log data that they’re looking at that tells them that. Get them to send it to you. It might reveal what the problem is on your end.

      Reply
  4. charlie says

    September 11, 2015 at 2:26 am

    paul, tremendous site. i always reference exchangeserverpro when dealing with anything exchange related. thanks for the great content!

    i am running into the issue where the root domain (www.domain.com) is hosted by external party so the initial autodiscover fails with an SSL mismatch error and i cant provision active sync devices because of this. is there anyway to ignore / bypass this? im not sure how else i can get around the issue as the hosting company can’t make changes to the SSL because of their NLB config.

    thanks again.

    charlie

    Reply
    • Paul Cunningham says

      September 11, 2015 at 6:02 am

      Put an SSL certificate on the website and then redirect the /autodiscover/ virtual directory to your on-prem server.

      If your web host can’t do this for you then find another web host. It’s a pretty simple thing that most of them can do.

      Reply
  5. Faisal Khan says

    June 25, 2015 at 7:00 pm

    First of all, great work Paul! whatever I do on exchange server, your blog is always there to help me out; appreciate that very well.

    I have my exhange server setup as;
    External DNS for mail server: mail.myCompanyExternalDomain.co.uk
    Acceptable domains in Exchange: myCompany1.co.uk & myCompany2.co.uk
    ServerName: MailServ01
    Local Domain: LDomain.local

    Now bearing this in mind, following are the SAN/UCC cert entries i can think of. Can you please confirm if they are correct.

    mail.myCompanyExternalDomain.co.uk
    autodiscover.myCompany1.co.uk
    autodiscover.myCompany2.co.uk
    autodiscover.LDomain.local
    Autodiscover.MailServ01.LDomain.local

    Reply
  6. Mkhumbi says

    May 12, 2015 at 1:45 am

    Hi Paul,

    Given that only one certificate can be bounded to IIS, how then do I solve my case, I have 2 acceptable domains, contoso.com and contosohq.com for instance and I have two SSL wildcard certificates for the domain. What’s happening is that I get certificate errors because I am only using contosohq.com certificate and users are configured with contoso.com. I have tried to use load balancer (KEMP) and install both certificate in there, still I receive the same results. Tried to create a separate IIS server for contoso, the OWA there works internally and externally with the rights certificates but still when configuring outlook with the other one it fails and when configured with the one working it will give errors regarding the other domain certificate. please assist.

    Reply
    • Paul Cunningham says

      May 12, 2015 at 9:54 am

      Use a SAN/UCC certificate.

      https://practical365.com/exchange-2010-ssl-certificates/

      Reply
      • Mkhumbi says

        May 12, 2015 at 9:38 pm

        Thank you Paul for your prompt response, I get your point but the issue I am having is that the two wildcard certificates are already in possession. I understand we could have easily got the UCC, (or SAN with all the domains) now that we have these two separate SSL wildcards certificate, is there a way to make it work or there isn’t? both of these domains are authoritative…

        Reply
        • Paul Cunningham says

          May 12, 2015 at 10:06 pm

          As you’ve already discovered, only one certificate can be bound to the IIS website.

          So no, there’s no way to make it work.

          Invest the few hundred dollars in a SAN/UCC certificate, you will save yourself a lot of wasted time and energy by just doing it the right way.

          Reply
  7. Neal says

    April 24, 2015 at 4:01 pm

    ok. So I have a certificate for server.mydomain,com which I use for OWA internally and externally and this is installed to my Exchange server. OWA works fine.
    What I hear you saying is that I need a separate certificate for OA. Ok BUT how can I configure two certificates (server.mydomain.com and autodiscover.mydomain.com ) within Exchange ?
    Both the virtual websites installed as Default can only be bound to only one SSL certificate

    I have external DNS set up for autodiscover and I have changed the External URL set to server.mydomain.com .

    so when the Outlook Client Connects I get a warning that server.mydomain.com certificate is not verified ! So it does work but the client is looking for autodiscover.mydomain.com even through the external URL is set to server.mydomain.com

    To sum up I have one certificate, I’ve set the External URL and Internal URL the same for OA and OWA
    i’m using the same cert for both becuase I can’t see how to install different certificates installed in Exchange. (I can’t see how)

    -It’s working it just gives the warning becuase its looking for autodiscover.mydomain.com
    – I have Port fowarding 443 firewall
    -Our website is hosted elsewhere so OA won’t resolve to “mydomain.com” Therefor I assume it resolves to autodiscover but
    -I am missing something.

    Thanks for your Blog

    Reply
    • Paul Cunningham says

      April 24, 2015 at 4:23 pm

      Only one SSL certificate can be bound to IIS. It should be a SAN/UC cert, or a wildcard. That way it is valid for multiple names.

      Some reading for you:
      https://practical365.com/exchange-2010-ssl-certificates/

      Reply
      • Neal says

        April 27, 2015 at 8:40 am

        Thanks Paul- Very much, I sort of figured something like that however why would OA from the external interface still allow access with a certificate warning- saying certificates don’t match-are you sure you want to continue?

        Reply
        • Paul Cunningham says

          April 27, 2015 at 5:31 pm

          Assuming your Outlook Anywhere hostname is included on the certificate, it’s possible that the first Autodiscover lookup (which goes to domain.com instead of autodiscover.domain.com) is hitting the web server that hosts your website.

          Reply
  8. Ivan says

    February 25, 2015 at 12:16 pm

    Hi Paul!

    If you have some time will you suppose about my case?

    My outlook auto configuration is working, but on the stage “Search for username@mydomain.com server setting” (see your outlook screenshot) I’m getting login/password challenge from my Exchange 2010sp3 server.

    A window appears where login field is set to UPN (e.g. usermame@mydomain.com). Then I change it to mydomainusername, enter the password and auto configuration succeed.

    I wonder why does my server force me to enter credentials the second time?

    Reply
    • Ivan says

      March 24, 2015 at 11:16 pm

      Solved!
      I just changed UPN to match SMTP domain.

      Reply
  9. Cody says

    February 6, 2015 at 2:14 am

    I’m not sure I like the SVR name record method of handling autodiscover. That causes a pop-up for the user. Most people try to avoid anything that may be perceived as an error.

    I think I’ll create a CNAME record pointing my other SMTP domains to my main autodiscover and just include those SMTP name spaces on the UCC cert.

    Reply
  10. Kuma says

    October 24, 2014 at 12:19 pm

    Attempting each method of contacting the Autodiscover service.
    The Autodiscover service was tested successfully.

    Additional Details

    Test Steps

    Attempting to test potential Autodiscover URL https://domain.com:443/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.

    Additional Details

    Test Steps
    Attempting to test potential Autodiscover URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml
    Testing of the Autodiscover URL was successful.

    domain.com and autodiscover.domain.com are directing to separate ip address. our web site is on separate public ip. Any opinion most welcome

    Reply
  11. Carol Ostos says

    April 16, 2014 at 9:33 am

    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!

    Reply
    • Paul Cunningham says

      April 20, 2014 at 11:09 pm

      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.

      Reply
      • Carol Ostos says

        April 23, 2014 at 11:17 am

        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.

        Reply
  12. Jack Cristi says

    March 25, 2014 at 1:39 pm

    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

    Reply
    • Paul Cunningham says

      March 26, 2014 at 9:17 pm

      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.

      Reply
  13. Jared says

    January 8, 2014 at 1:05 pm

    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

    Reply
    • Paul Cunningham says

      January 8, 2014 at 1:24 pm

      Regarding wildcards:

      https://practical365.com/exchange-2010-wildcard-ssl-certificates/

      I never use them. Your mileage may vary.

      Reply
  14. ExchangeHasna says

    July 7, 2013 at 9:24 pm

    In my organization I have a casarray.domain.com cluster Bitween CASHUB01 and CASHUB02, My OWA work good. But my outlook donc work, he could not connect to the server.

    When I run Test-OutlookWebSrvice I get the following error:

    RunspaceId : a3a049ae-7736-4469-ac7d-16682be696fc
    Id : 1004
    Type : Error
    Message : The certificate for the URL https://mail.domain.com/EWS/Exchange.asmx is incorrect. For SSL to work, the
    certificate needs to have a subject of mail.domain.com, but the subject that was found is CASHUB01. Consi
    der correcting service discovery, or installing a correct SSL certificate.

    And when I run the Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri commande I got:

    Name : CASHUB01
    AutoDiscoverServiceInternalUri : https://cashub01.domain.com/Autodiscover/Autodiscover.xml

    Name : CASHUB02
    AutoDiscoverServiceInternalUri : https://cashub02.domain.com/Autodiscover/Autodiscover.xml

    Thank

    Reply
  15. Pooria says

    May 3, 2013 at 9:24 pm

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

    Reply
  16. Pooria says

    May 3, 2013 at 11:30 am

    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 ?

    Reply
    • Paul Cunningham says

      May 3, 2013 at 11:52 am

      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.

      Reply
      • Pooria says

        May 3, 2013 at 12:01 pm

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

        Reply
        • Paul Cunningham says

          May 3, 2013 at 7:05 pm

          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.

          Reply
  17. Pooria says

    May 2, 2013 at 11:33 pm

    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

    Reply
    • Paul Cunningham says

      May 3, 2013 at 11:01 am

      Do you have a firewall or reverse proxy in front of Exchange?

      Reply
      • Pooria says

        May 3, 2013 at 11:07 am

        No I don’t, we are using hub server but we have AVG installed and OWA works fine internally and externally.

        Reply
        • Paul Cunningham says

          May 3, 2013 at 11:18 am

          Unless your Exchange server is named “localhost.localdomain” then that sounds like your external connections are hitting some other firewall or reverse proxy that is doing SSL proxy.

          Or its possible something in the autodiscover process is making the client connect elsewhere. I suggest running the Outlook Anywhere test here:

          https://www.testexchangeconnectivity.com/

          Reply
  18. Jonathan says

    February 26, 2013 at 12:44 am

    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?

    Reply
    • Jonathan says

      February 26, 2013 at 12:59 am

      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?

      Reply
  19. TonyH says

    October 4, 2012 at 3:34 am

    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

    Reply
  20. Andrew DeVries says

    September 1, 2012 at 4:24 am

    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

    Reply
    • Paul Cunningham says

      September 1, 2012 at 8:34 pm

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

      Reply
      • Doug says

        February 22, 2013 at 11:17 am

        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

        Reply
  21. David Szpunar says

    June 20, 2011 at 3:22 pm

    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!).

    Reply
    • Ludwig Lemnos says

      August 27, 2013 at 12:25 am

      Thank you ! The DNS SRV record worked like a charm.

      Reply
    • Cody says

      February 6, 2015 at 2:16 am

      Yeah that does cause a pop-up though when the system redirects the users request. If your users are like mine this will cause a service desk call.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • The Practical 365 Weekly Update: S2, Ep 8 – What to expect in 2021, Solarigate, TLS in Exchange and new Teams updates
  • Security updates released for Exchange and SharePoint Servers 2010 to 2019
  • The Practical 365 Weekly Update: S2, Ep 7 – Urgent Exchange security updates, new Teams features launch
  • How to train your users against threats with Attack Simulation Training
  • Fall 2020 roundup of compliance updates
Practical 365

Related Posts

Related Posts

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials. Read more...

Find out more about advertising with us.

Contact us


Subscribe to our newsletter
  • Facebook
  • Twitter
  • RSS
  • YouTube

Copyright © 2021 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland