0

I was exploring SAN certs and was able to connect to the machine with domains specified in the SAN fields during CSR creation. But I was unable to connect to the machine with the common name specified in the CSR.

Below error is what I get on connecting, even though the servers certificate has the common name:

curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

What am I missing?

PasWei
  • 722
  • 3
  • 14
SandMan
  • 1
  • 1
  • Related: https://security.stackexchange.com/questions/172626/chrome-requires-san-names-in-certificate-when-will-other-browsers-ie-follow https://security.stackexchange.com/questions/256509/what-is-the-security-advantage-of-requiring-the-cn-to-be-in-the-san-list https://security.stackexchange.com/questions/192979/client-certificate-common-name-subject-alternative-name – mti2935 Aug 07 '22 at 11:41

1 Answers1

1

Using the common name for domains is obsolete for a long time. To cite from RFC 2818 which was written more than 20 years ago:

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.

Chromium based browsers ignore the common name completely, others modern browsers might still use the common name but only if no Subject Alternative Name is present.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424