TLS certificates for hosts and domains must somehow identify what hostname (or names) they're for. Historically there have been two ways to do this. The first way was a specific sub-field, the CN or CommonName, of the certificate's overall Subject Name. This had the problem that it could only have one name. When people started wanting to have TLS certificates that covered more than one name, they invented another mechanism, the Subject Alternative Name (SAN) extension.

As a practical matter, all vaguely modern software that wants to properly validate TLS certificates has supported (and often preferred) Subject Alternative Names for some time. A great many TLS certificates in the wild are for multiple hosts and it's generally unlikely that the host you're connecting to is the one name that the system chose to put in the CN field; software that only supports CN cannot validate those TLS certificates. As a matter of timing, SANs have been theoretically mandatory since 2002 and checking only SANs has been theoretically required since 2011 (which means that since 2011 or earlier, the CN was supposed to always be one of the SANs).

These days, any remaining support for looking at TLS certificate CommonName to validate TLS certificates is getting more and more extinct (and more so than I expected when I started writing this entry). In the browser realm, Chrome apparently turned it off in 58, released in 2017, and then threw out the option to check it again in Chrome 65 (from the comment on my old entry, which was ironically written shortly before Chrome did this). Firefox is said to have removed support in version 48, from August of 2016. Safari apparently stopped looking at CommonName in iOS 13 and macOS 10.15, which I believe date from late 2019. This Go change also talks about how browsers removed it in 2019 ('last year' for a mid 2020 change).

In non-browser TLS code, Go started ignoring CN by default in Go 1.15 (released in August of 2020) and this will be the only option starting in Go 1.17 (to be released in August of 2021), per here. Since Firefox doesn't support CN any more, I assume that NSS doesn't either, since NSS is basically Firefox's underlying TLS implementation. I have no idea what other TLS libraries are doing, but I would expect that many of them will support CommonName for some time to come; TLS libraries are historically behind browser practices. Hopefully they are all following the 2011 requirement to check only SANs when SANs are present (which they should always be in public certificates).

Probably TLS certificates will continue to contain CommonName fields for a long time to come. Having a Subject Name in general is common (although apparently not actually required) and the CN is a standard (although not required) part of the Subject Name, so you might as well throw it in. Even Mozilla and Let's Encrypt (still) have TLS certificates with CNs. However, since I checked this now, the current CA/Browser Forum baseline requirements (version 1.7.3) allow but don't require CommonName (section 7.1.4.2.2, which says that it's 'discouraged, but not prohibited'). Given how conservative most Certificate Authorities are, I expect them to be issuing TLS certificates with CommonName fields until they're required to stop.

(An interested party could scan Certificate Transparency logs to see if there were very many issued certificates without CNs. Probably there are some; someone must have tried it out at some point through an official CA.)

PS: no-common-name.badssl.com has a TLS certificate without a CN, or at least it's supposed to (via), but the TLS certificate is expired right now as I write this entry so it's hard to test how client software behaves. See also, which pointed me to no-subject.labs.vu.nl, which has a currently valid TLS certificate with no Subject Name at all.