Thanks for doing this experiment! That’s really useful to know.
Unsurprisingly, it’s fine in Firefox 62 and Chromium 69 on Linux. Also fine in curl 7.47, wget 1.17, and Python requests 2.9.1.
(Is it possible that SSL Labs has already collected some form of this data? I know they have a bunch of simulated browser handshakes—but maybe that’s focused only on ciphersuites and then on random other compatibility concerns that Ivan Ristić happened to already know?)
Reasoning: If we omit CommonName, we would actually have to omit the Subject field entirely (and make the SANs critical), since there would be nothing in it.
I may have access to some other old stuff - but I suspect that if you want to validate with some of the older ones, you’ll need to re-enable some of the insecure ciphers on that endpoint. It looks like it is currently pretty restrictive in only supporting current ones.
Probably there is not much testing anything that uses OpenSSL 0.9.8 series or lower (or the GnuTLS/NSS equivalents), as they have fatal flaws other than their handling of a missing subject.
Yes, the ciphers and SNI is pretty annoying for this test. Unfortunately that website in managed by Google, I doubt they will change the configuration for our test.
The majority of certificates probably use the CN field of the Subject attribute to describe the entity. RFC6125 recommends that the SubjectAltName attribute should be used. But it’s only a recommendation.
Question: Why is this useful to omit the Subject attribute?
This was covered briefly in the other thread that spawned this compatibility testing thread:
We originally thought to do this by copying the serial number field into the subject, but it’s been suggested that the Baseline Requirements would term this “Subject Identity Information,”
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.
Since Let’s Encrypt uses the CA/Browser Forum domain-validated OID (2.23.140.1.2.1) in its certificates, the certificates are not supposed to have Subject Identity Information
I think the best short-term solution would probably be to set up a custom test domain that you can continually tweak parameters for.
@cpu Do you think it would be interesting/feasible to do it? As all Let's Encrypt certificate generation is automatic, maybe it's not a good idea to do it now with a Let's Encrypt certificate, but I think it would really show the real compatibility problems (including if the certificate is refused because the chain is not trusted).
Thank you for that contribution. Your website indeed solve the SNI problem. (sadly it use the same cipher list as badssl.com and same DH parameter size)
My understanding: OID = 2.23.140.1.2.1specifies that the certificate is a DV certificate.
But where to find the information that a DV certificate can omit the Subject attribute?