On Tue, Sep 17, 2013 at 10:28 PM, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > ... > If your clients are RFC 5280 compliant (such as a web browser), then > here are the guides: > > Baseline: https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf > Extended Validation: https://www.cabforum.org/Guidelines_v1_4_3.pdf > > ... > Section 9.2.2 of the baseline guide also states: "if present, this > field [CN] MUST contain a single IP > address or Fully-Qualified Domain Name that is one of the values > contained in the Certificate’s subjectAltName extension". The SAN is > covered in section 9.2.1. > > So the question becomes, is the IP address also listed in the SAN? It looks like Outlook does want that CN in the SAN (with some hand waiving). From http://support.microsoft.com/kb/2783881: CAUSE Outlook uses the domain name part of the user's SMTP address to query DNS. In this example, the domain name is contoso.com. Outlook resolves contoso.com to an NS record for the DNS server. On the DNS server, IIS is configured to use an SSL certificate. The SSL certificate subject is DC1.contoso.com. However, Outlook tries to connect to https://contoso.com/autodiscover/autodiscover.xml. The certificate name mismatch causes Outlook to present the warning described earlier. WORKAROUND Method 1: Reissue a certificate that includes the domain name as the Subject Alternative Name Reissue a certificate that includes the domain name (contoso.com) as the Subject Alternative Name. This solution may be appropriate if you cannot implement client-side registry keys, or have only a limited number of domains. ... Can you verify the certificate is well formed per the Baseline Guide? Jeff