Why must a web server certificate list its host name in the Subject Alternative Name (SAN) extension, and not only in the Common Name?

Question

Accepted Answer

Browsers check the host name only against the SAN; Chrome stopped falling back to the Common Name in 2017, so a certificate without SAN entries fails with ERR_CERT_COMMON_NAME_INVALID.
Historically the host name sat in the subject's Common Name (CN=www.example.com). That field holds exactly one free-text name, and the standards have said since RFC 2818 (2000) that the SAN extension is the correct place: it can list several typed names (DNS:www.example.com, DNS:example.com, IP addresses). Chrome 58 (2017) enforced this and ignores the CN entirely; other browsers followed.
That is why the request in this lab needs a config file with
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.gXXX.ckteck.com

instead of a quick one-line openssl req. And it explains the warning on the CA's own /certsrv page: the certificate generated during CA installation has no SAN, so Edge rejects it for name mismatch even though the chain itself is trusted.
Go deeper:

heise: Chrome blockt Zertifikate mit Common Name (2017) — background to the Chrome 58 change (German).
 Wikipedia: Public key certificate — the Subject Alternative Name section and multi-domain certificates.