Users of Google Chrome version 58 (released March 2017) and later will receive a certificate alert when browsing to HTTPS-sites if the certificate only uses Common Name and does not use any Subject Alternative Name (SAN) values. This has been ignored and for many years the Common Name field was exclusively used. The Chrome developers finally had enough with the field that refuses to die. In Chrome 58 and later, the Common Name field is now ignored entirely.

Chrome - Certificate warning - Invalid commonName

Chrome – Certificate warning – NET::ERR_CERT_COMMON_NAME_INVALID

The reason for this is to prevent homograph attack – which exploits characters which are different but look similar. The lookalike characters can be used for phishing and other malicious purposes. For instance, the English letter “a” looks identical to the Cyrillic “a”, but from a computers point of view these are encoded as two entirely different letters. This allows domains to be registered that look just like legitimate domains.

Some organizations with an internal or private PKI have been issuing certificates with only the Common Name field. Many often do not know that the “Common Name” field of an SSL certificate, which contains the domain name the certificate is valid for, was phased-out via RFC nearly two decades ago (RFC 2818 was published in 2000). Instead the SAN (Subject Alternative Name) field is the proper place to list the domain(s), which all publicly trusted certificate authorities must abide by, has required the presence of a SAN (Subject Alternative Name) since 2012.

Publicly-trusted SSL certificates have been supporting both fields for years, ensuring maximum compatibility with all software – so you have nothing to worry about if your certificate came from a trusted CA like Digicert.

Below is an example of a correctly issued certificate with Common Name and Subject Alternative Name. - Common Name – Common Name - Certificate Subject Alternative name – Subject Alternative Name

RFC 2818 – Common Name deprecated by Google Chrome 58 and later

”RFC 2818 describes two methods to match a domain name against a certificate: using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName.


The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. However, the commonName is ambiguous, and because of this, support for it has been a source of security bugs in Chrome, the libraries it uses, and within the TLS ecosystem at large.