Article ID: 2772058 - View products that this article applies to.
In a dedicated or International Traffic in Arms Regulations (ITAR) Microsoft Office 365 environment, a user receives a Security Alert dialog box that includes the following error message:
For example, the Security Alert dialog box resembles the following:
The name on the security certificate is invalid or does not match the name of the site.
Collapse this imageExpand this image
This issue may occur under the following circumstances:
If the user clicks Yes, the user can continue the operation. However, if the user clicks No, the Autodiscover lookup fails. The failure of the Autodiscover lookup prevents all the following features from working as expected:
Generally, this issue occurs when the URL that you are trying to access is not listed in either the Subject or the Subject Alternative Name (SAN) of the Secure Sockets Layer (SSL) certificate for the website. Although different organization's configurations may be slightly different, this issue generally occurs because the organization's Autodiscover Domain Name System (DNS) records are configured incorrectly.
To resolve this issue, you may have to change your Autodiscover DNS records (internal, external, or both). However, these changes should not be taken lightly, because the Autodiscover feature may not function if DNS records are configured incorrectly.
Before you change the Autodiscover DNS records, you should understand how the Outlook client tries to locate the Autodiscover service. The Outlook client tries to locate the Autodiscover service by using the following fundamental order of operations. However, the step in which the Autodiscover service is located varies from deployment to deployment. This location depends on whether there is an on-premises solution in co-existence and what the specific on-premises email environment is (for example, an on-premises Microsoft Exchange Server, an on-premises Lotus Notes, or another environment).
The following table displays the fundamental order of operations for how the Outlook client locates the Autodiscover service:
In summary, the Autodiscover service may be resolved by using either an A record, a CNAME record, or an SRV record. To determine which records are used currently, run the following commands at a command prompt or in Windows PowerShell:
Collapse this tableExpand this table
autodiscover.proseware.comHowever, as we mentioned in the "Cause" section, this URL is not listed in the SAN of the SSL certificate that is used by the Autodiscover service. For example, see the following screen shot:
Collapse this imageExpand this image
To resolve this issue, use one of the following methods, as appropriate for your situation.
Method 1: Add the Autodiscover URL to the SAN of the Autodiscover site's SSL certificate (not the preferred method)Although this method is technically workable, this is not the preferred method in the current service design because of the cost and labor that is involved in distributing the newly updated certificates. If this resolution method is the only workable solution, you should submit a Configuration Request (CR) to request that the SSL certificate be updated and deployed. However, the CR may be declined in favor of method 2 unless an exceptionally strong business justification is provided.
Method 2: Replace the existing A record by using an SRV record that points to a namespace that is already in the SAN of the SSL certificate (preferred method)This is the preferred resolution method in the current service design because the existing SSL certificate does not have to be updated and deployed. According to the fundamental order of the operations that are listed earlier in this section, the organization may implement the new record by using a controlled and tested way to prevent outages of the Autodiscover service.
To resolve this issue, follow these steps:
For more information about the Autodiscover service, go to the following Microsoft TechNet website:
Understanding the Autodiscover Service