Difference between untrusted-root.badssl.com and self-signed.badssl.com

[GianpaoloPedrazza]

Dear all, I noticed that the SSL certificate used by untrusted-root.badssl.com was signed by a self-signed root CA certificate (the entire chain is sent), while the one used by self-signed.badssl.com is just a self-signed certificate. So there is not such a big difference between the two scenarios, because both hosts have an untrusted self-signed certificate somewhere in the certificate chain. In my opinion, it would be more sensible to configure the host untrusted-root.badssl.com differently. Sending just his own certificate without the root CA certificate would be perfect for the testcase "the certificate cannot be verified", which is uncovered at the moment.

[lgarron]

396 changed untrusted-root to include the root.

@sleevi @april @christhompson, what would you think of unknown-root for the old untrusted-root behaviour?

[sleevi]

There is a meaningful difference between the two right now that impacts common verifiers - plenty of libraries have differing behaviors for whether directly issues by a root versus transiting an intermediate.

Simply having an incomplete chain is not really testing any particular behavior, other than “I don’t have all the facts,” and I’m not aware of any client ever having had a bug, issue, or incompatibility there. I would suggest adding a third, “incomplete-chain”, if that’s the a thing worth testing, and it’s unclear if you want a positive test case (e.g. trusted with intermediates omitted) or negative test case (untrusted with intermediates omitted)

[GianpaoloPedrazza]

I think you mean something different than me. An example of host sending an incomplete chain in the TLS handshake is https://sts.ajax.nl. If you get its SSL certificate, you will find in the Authority Information Access an URI, where you can download the missed intermediate certificate from and add it to the CA bundle. There are some clients able to perform this operation automatically. What I mean is the scenario where no intermediates are involved, but the SSL certificate was signed by an untrusted CA.

[sleevi]

That’s what I said.

There’s four scenarios here. Right now, of those, three exercise interesting and unique paths in client verification code (including AV and MITM boxes) which have had interesting security or compatibility issues. One of these paths - the “issued from a chain/root I don’t have and thus probably don’t trust” is the least interesting, from a code coverage perspective.

I was trying to explain that the current two test cases do in fact test different things and offer different coverage of different behaviors - despite them both using “self-signed” certificates. The inclusion of the root was intentional - the prior behavior, omitting the root, was the test case I mentioned as least interesting, because it offered the least coverage of client behavior.