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