2023-09-14 What Crap is This and Why Did We Let it Infect Gemini?

I recently changed the certificate for AuraGem because it wasn't being validated properly in some Gemini browsers.

I found the culprit. I put auragem.letz.dev in the Common Name (CN), since it's the common address for the capsule, and I put the alternative domains in the Subject *Alternative* Name (SAN) field. Should be fine, right?

NOPE! It *was* fine before 2011, but apparently in 2011, RFC 6125 was published which includes Section 6.4.4 which basically states that if a SAN exists, the CN MUST NOT be checked. When that was published, every website that had its cert with the main domain in the CN but not the SAN became invalid as soon as this RFC recommendation was implemented into browsers. This also applies to CAs and HTTP over TLS specs as well.

RFC 6125, Section 6.4.4

To summarize, the Common Name is NOT the Common Name, it's useless, and the Subject Alternative Name (SAN) field is not for Alternative fields, but for all names. WHAT?! Holy crap, this is ridiculously stupid.

Anyways, we let this crap affect Gemini, so now there are browsers that don't check CN when the domain is in the SAN, and some browsers do still check the CN. It's like... what exactly is the point of this craziness? What does not checking the CN gain us? Is it some security vulnerability? Why does CN still exist and why is it still used in documentation on the official openssl website then? And why did we just decide that the names of fields shouldn't match their function anymore?

So... I changed the certificate for AuraGem, because it wasn't being validated properly in some Gemini browsers, and now every browser will complain that the cert changed.