Compatibility testing of No Common Name


#1

Following that thread:

If you want to help, please visits https://no-subject.badssl.com/ and report if it’s working or not on your configuration (Browser/OS)

Particularly old and uncommon configurations are interesting!

I’ll update this post with the results.

Working:

  • Windows 8 - Firefox 62

  • Windows 8 - Chrome 70

  • Windows 8 - IE 11

  • Windows 8 - Opera 55

  • Windows 8 - Brave 0.24

  • Linux - Firefox 62

  • Linux - Chrome 69

  • Linux - curl 7.47

  • Linux - wget 1.17

  • Linux - Python requests 2.9.1

  • OSX 10.6.8 - Safari 5.1.10

  • OSX 10.6.8 - Firefox 48.0.2

  • OSX 10.6.8 - Chrome 49.0

  • Android 9 - Chrome 69

  • Android 5 - Firefox 62

  • Android 5 - Brave 1.0.68

  • Android 5 - Samsung browser

  • Android 4.2.2 - default browser

  • Android 4.2.2 - Firefox 57.0.

  • onion omega/LEDE 17 - wget 1.19.2

No working:

  • ub 12.04.3 - curl-7.22.0
  • ub 12.04.3 - wget 1.13.4
  • ub 12.04.3 - libio-socket-ssl-perl (1.53-1)
  • centos 4.7 - curl 7.12.1
  • centos 4.7 - wget 1.10.2

Note: that specific test website require SNI, so the test will fail for browsers without SNI support (ex. : Android 2.3.7, IE8/XP) and on Java 6u45 (DH parameters size): https://www.ssllabs.com/ssltest/analyze.html?d=no-subject.badssl.com


#2

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?)


#3

Let’s find out: https://twitter.com/kermiite/status/1043252840704212992


#4

Android 5: Firefox 62, Brave 1.0.68, Chrome 46,Samsung browser: ok


#5

wow, it’s weird to see my picture on Twitter like that (!)


#6

I’m afraid I picked the wrong entry on badssl. What we actually want is https://no-subject.badssl.com/.

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.


#7

This also works in the browsers that I tested before.


#9

I’ve converted it to a wiki now.


#10

OSX 10.6.8 (last OSX to support 32bit Macs) works with Safari 5.1.10, Firefox 48.0.2 and Chrome 49.0.

Android 4.2.2 works with default browser and Firefox 57.0.

(That’s the oldest stuff I have physical access to.)


#11

Thanks. I saw you make the necessary edit too, perfect!


#12

Thank you very much!


#13

curl-7.22.0 - fails - ub 12.04.3
wget 1.13.4 - fails - ub 12.04.3
curl 7.12.1 - fails (no sni?) - centos 4.7
wget 1.10.2 - fails (no sni?) - centos 4.7
wget 1.19.2 - ok - onion omega/LEDE 17
libio-socket-ssl-perl (1.53-1) - fail - ub 12.04.3


#14

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.


#15

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.


#16

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.


#17

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?


#18

Looks like Buypass produces an empty subject for a CSR made with ‘-subj /’, so I’ve used it to whip up a site:

https://no-subject.labs.vu.nl/

I used Mozilla’s “old” for the cipher list.


#19

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


#20

I opened an issue about the SNI & cipher list compatibility: https://github.com/chromium/badssl.com/issues/368

It was suggested:

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)

https://www.ssllabs.com/ssltest/analyze.html?d=no-subject.labs.vu.nl also reports IPv6 connectivity problem?


#21

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?