You really shouldn't need CN (but it's convenient for humans) however there are a bunch of other interesting things in the X.509 certificate, lets look at the one for this site:

Issuer: We need to know who issued this cert, then we can check whether we trust them and whether the signature on the certificate is indeed from them, and potentially repeat this process - this cert was issued by Let's Encrypt's E5 intermediate

Validity: We need to know when this cert was or will be valid, a perfectly good certificate for 2019 ain't much good now, this one is valid from early May until early August

Now we get a public key, in this case a nice modern elliptic curve P-256 key

We need to know how the signature works, in this case it's ECDSA with SHA-384

And we need a serial number for the certificate, this unique number helps sidestep some nasty problems and also gives us an easy shorthand if reporting problems, 05:6B:9D:B0:A1:AE:BB:6D:CA:0B:1A:F0:61:FF:B5:68:4F:5A will never be any other cert only this one.

We get a mandatory notice that this particular certificate is NOT a CA certificate, it's just for a web server, and we get the "Extended key use" which says it's for either servers or for clients (Let's Encrypt intends to cease offering "for client" certificates in the next year or so, today they're the default)

Then we get a URL for the CRL where you can find out if this certificate (or others like it) were revoked since issuance, info with a URL for OCSP (also going away soon) and a URL where you can get your own copy of the issuer's certificate if you somehow do not have that.

We get a policy OID, this is effectively a complicated way to say "If you check Let's Encrypt's formal policy documents, this certificate was specifically issued under the policy identified with this OID", these do change but not often.

Finally we get two embedded SCTs, these are proof that two named Certificate Transparency Log services have seen this certificate, or rather, the raw data in the certificate, although they might also have the actual certificate.

So, quite a lot more than you listed.

[A correct decoder also needs to actually verify the signature, I did not list that part, obviously ignoring the signature would be a bad idea for a live system as then anybody can lie about anything]

> You really shouldn't need CN (but it's convenient for humans)

Is this finally the case now? About 5 years back IIS would fail to load a certificate without a CN, despite the field being deprecated since 2000.

And who would run IIS? A bunch of janky/dodgy/shady marketing affiliates, at least. Quite common in the gambling industry.