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 https://autodiscover.domain.com, 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 https://webmail.domain.com/Autodiscover/Autodiscover.xml
By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN).
https://CASServer/Autodiscover/Autodiscover.xml
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):
- https://domain.com/autodiscover/autodiscover.xml
- https://autodiscover.domain.com/autodiscover/autodiscover.xml
Every client I’ve ever worked with leverages autodiscover.domain.com and does not rely on domain.com. Taking a close look at the URLs, we will utilize https. This means that we will need the autodiscover.domain.com 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.
- webmail.domain.com
- autodiscover.domain.com
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 autodiscover.domain.com. 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 https://domain.com/autodiscover/autodiscover.xml is attempted before https://autodiscover.domain.com/autodiscover/autodiscover.xml. https://domain.com may be going to your Public Facing website. This isn’t generally a problem. Outlook will detect that https://domain.com is not Exchange and Outlook will still fallback to https://autodiscover.domain.com and then eventually connect to Exchange.
However, if your https://domain.com site is having a certificate error even in a Web Browser, Outlook will prompt you with the certificate error and the fallback process to https://autodiscover.domain.com will fail. Your public facing website is most likely https://www.domain.com, but the website has been set up to allow for https://domain.com, and SSL is activated on https://domain.com. But, your public facing website only has the www.domain.com name on the cert. It does not have domain.com on the certificate. It is this reason that going to https://domain.com will cause a certificate error in a web browser or in Outlook.
There are one of two fixes for this:
- Add the domain.com to your Public Facing Website’s certificate. That way, Outlook makes a successful connection to https://domain.com, determines it’s not Exchange, and will fallback to attempting autodiscover via https://autodiscover.domain.com. (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 autodiscover.domain.com. (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).
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 https://domain.com 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 “domain.com” on the client via the etc/hosts file during Outlook setup and everything suddenly worked as expected.
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 (domain.com, autodiscover.domain.com, remote.domain.com … 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.
Regards
Mike
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 (domain.com, autodiscover.domain.com, remote.domain.com … 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.
Regards
Mike
Briliant artcle. Thanks a ton. I was pulling my hair out trying to figure this out.
Pat
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 Domain.com. Now they had us change our primary smtp address for every user to say newdomain.org. We have no service records internal or external, nothing on our SAN cert for autodiscover.newdomain.org, 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 autodiscover.newdomain.org 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.
Suggestions?
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):
https://domain.com/autodiscover/autodiscover.xml
https://autodiscover.domain.com/autodiscover/auto…
– it means the first uri for Outlook to check must be https://domain.com/autodiscover/autodiscover.xml, 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…???
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, exchange_server.domain.com.
don't know if I'm happy disabling SSL. I wouldn't suggest that as a fix
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…
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. http://technet.microsoft.com/en-us/library/jj5913…
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.
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 domain.com 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 domain.com/autodiscover/autodiscover.xml?__The only thing different i see is the SCP sequence, since we changed the 2007 systems to use legacyexchange.domain.com 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 legacyexchange.domain.com and because the user is on 2010 it replies with a 302 redirect to use webmail.domain.com for autodiscover. And the next SCP connection attempt goes to webmail.russell.com 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
What is even better is to leverage an _autodiscover._tcp.domain.com 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.