9

I have generated a certificate for an internal server that is also accessible externally. According to this SO answer the CN and the SAN fields compliment each other and so accordingly I set the CN to server.domain.local and in the SAN I have DNS:server.domain.tld

However, with Chrome at least, I can browse to server.domain.tld (SAN entry) without error but I get a common name mismatch error at server.domain.local (CN)

Is this an implementation error in NSS on Chrome or have I done something wrong? Should I have both server.domain.local and server.domain.tld in the SAN field?

Community
  • 1
  • 1
JonoCoetzee
  • 969
  • 2
  • 15
  • 30

3 Answers3

10

.. the CN and the SAN fields compliment each other ..

That is only true in the general PKI case, but specific protocols have different behavior. The relevant RFC for checking the certificate in HTTPS is RFC2818 (or later RFC6125) which states:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

That means, if you have a SAN section it must contain all names, because the CN will not be checked.

Community
  • 1
  • 1
Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • I believe you cuz that's what I'm experiencing IRL but what about RFC 5280 (Section 4.1.2.6) that the other answer quotes? – JonoCoetzee Sep 22 '14 at 09:50
  • RFC5280 is only general for PKI structures. RFC2818 and RFC5216 instead deal with certificate verification in the context of specific application protocols. For example RFC5280 explicitly does not address handling of wildcards, while RFC2818 does. Yes, this is all very confusing :( – Steffen Ullrich Sep 22 '14 at 10:31
  • Were you not referring to RFC 6125 instead of 5216? – Bruno Sep 22 '14 at 13:01
  • The IETF and RFCs have nothing to do with this problem. The CAs and Browsers issue under a different set of policies. If Jono wants to play well with Browsers, then he needs to observe the CA/B BR and EV Guide. – jww Sep 23 '14 at 05:49
  • @jww: while I find information about issueing and revoking certificates by the CAs in the guides you mentioned I don't find any information about the verification process as implemented in the browsers. Could you point me please to the relevant part of the documents? – Steffen Ullrich Sep 23 '14 at 08:13
7

the CN and the SAN fields compliment each other and so accordingly I set the CN to server.domain.local and in the SAN I have DNS:server.domain.tld

No (but that post is kind of old now).

Placing a DNS name is the Common Name (CN) is deprecated by both the IETF and CA/Browser Forums. You should place all DNS names in the Subject Alternate Name (SAN). Use the CN for a friendly name like "Example LLP" since its displayed to the user.

According to the CA/Browser Baseline Requirements (BR), a DNS name in the CN must also be present in the SAN. See CA/B BR, Section 9.2.

Chrome at least, I can browse to server.domain.tld (SAN entry) without error but I get a common name mismatch error at server.domain.local (CN)

Chrome is correctly rejecting the certificate if server.domain.local is present in the CN, but is not present in the SAN. Its a violation of the CA/B BR if its not present in both.

Should I have both server.domain.local and server.domain.tld in the SAN field

Yes, place both DNS names in the SAN. Don't put a DNS name in the CN. Use the CN for a friendly name.

For completeness, CA/B stands for CAs and Browsers. They have their own little closed club, and they have their own set of policies for issuing certificates. Don't expect browsers to do things as specified in the IETF docs.

And if you are validating X509 certificates used in the wild issued by a CA that is a member of CA/B, then you should validate using the CA/B BR, and not the IETF docs.

jww
  • 97,681
  • 90
  • 411
  • 885
3

The original question has been answered, but I'd like to rebut a point made in one of the answers.

Use of the CN for a friendly name, while appealing and sensible to me, is not supported by the CA/B BRs. In prior version of the CA/B BRs, this was section 9.2.2, but it appears to have recently moved. https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf

7.1.4.2.2. Subject Distinguished Name Fields

a. Certificate Field: subject:commonName (OID 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or Fully‐Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension.

Respectfully, --obivon

obivon
  • 31
  • 1