Why is a v3 extension needed for a X.509 certificate to be used to test HTTPS on localhost?

Question

I'm learning how to test HTTPS locally and found that articles written before ca. 2019 (e.g., 1, 2, 3) contain only a few steps, whereas later posts (e.g., 4, 5, 6, 7, 8, 9) always make sure that v3 extensions are also configured.

Why is this?

Answer 1

As of 8/15/2023, the reasons seem to be specific to Chrome / Chromium as it won't process self-signed certificates without the following X.509 v3 extensions set:

• subjectAltName

  See Chromium mailing list post Intent to Remove: Support for commonName matching in certificates.

• basicConstraints (RFC 5280, section 4.2.1.9 "Basic Constraints")

  • CA:TRUE

    See this Stackoverflow answer. Couldn't find any official report for this one, and the fact that the OpenSSL line below produces a working certificate (at least, in Chrome 115.0.5790.170), this may be wrong - it may just need to be present.

  • Path Length (pathlen or pathLenConstraint)

    Came across the claim that "Chrome now rejects TLS certificates containing a variable known as pathLenConstraint or sometimes displayed as Path Length Constraint" (1/10/2023), but couldn't find any source substantiating it. (Here's a Stackoverflow answer elaborating on what it does.)

---

I've been using the following one-liner lately to produce a private key and a self-signed certificate for testing HTTPS in Chrome and Safari:

openssl req -x509 -new -nodes                                      \
  -newkey RSA:2048                                                 \
  -days 365                                                        \
  -subj '/C=US/ST=Denial/L=Earth/O=Dis/CN=anything_but_whitespace' \
  -addext 'subjectAltName = DNS:localhost'                         \
  -addext 'authorityKeyIdentifier = keyid,issuer'                  \
  -addext 'basicConstraints = CA:FALSE'                            \
  -addext 'keyUsage = digitalSignature, keyEncipherment'           \
  -addext 'extendedKeyUsage=serverAuth'                            \
  -out self-signed-server-and-root-ca.crt                          \
  -keyout server-and-root-ca-private.key

Firefox is a whole another story though as it has different rules and also uses its own trust store, effectively requiring one to use 2 key-pairs.

---

Notes on subjectAltName

• X.509 Extensions - IBM Documentation

  Certificate extensions were introduced in version 3 of the X.509 standard for certificates. These v3 extensions allow certificates to be customized to applications by supporting the addition of arbitrary fields in the certificate. X.509 v3 extensions provide for the association of additional attributes with users or public keys. Each extension, identified by its OID (Object Identifier), is marked as “Critical” or “Non-Critical,” and includes the extension-specific data.

• RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, section 4.1.2.6. Subject

  The subject field identifies the entity associated with the public key stored in the subject public key field.

• Excerpts from How do Common Names (CN) and Subject Alternative Names (SAN) work together? - Stack Overflow

  RFC 5280, section 4.1.2.6 says "The subject name MAY be carried in the subject field and/or the subjectAltName extension". This means that the domain name must be checked against both SubjectAltName extension and Subject property (namely its common name parameter) of the certificate.

  as per RFC 6125, published in 2011, the validator must check SAN first, and if SAN exists, then CN should not be checked.

  To be absolutely correct you should put all the names into the SAN field.

  CABForum Baseline Requirements[: ] If there are SANs, then CN can be ignored. -- At least if the software that does the checking adheres very strictly to the CABForum's Baseline Requirements.