1160936 - certificate chain in random order must be prohibited as per TLS RFC

Status: RESOLVED DUPLICATE of bug 619445

(Core :: Security: PSM, defect)

Description

[dansmith]

Attachment: certificate chain: wireshark output vs Firefox ouput

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150417180217

Steps to reproduce:

Go to https://auxmoney.com


Actual results:

Firefox validated the certificate chain


Expected results:

Firefox should have failed to validate the certificate chain

Comment 1

[dansmith]

openssl s_client -connect www.auxmoney.com:443
returns an error code.

Relevant RFC which states "Each following certificate MUST directly certify the one preceding it"
https://tools.ietf.org/html/rfc5246#section-7.4.2

Comment 2

[Dave Garrett]

The basic answer on this topic seems to be that in comparison to all of the other problems TLS has in various areas, nobody cares about this at all. ;)

So long as it is a valid chain, clients generally are willing to validate it without caring about the order in the list. After a bit of Googling, I think this probably evolved because some server implementations didn't have particularly smart certificate chain configuration and could make certs ordered just like this.

I'll bring this topic up on the TLS WG mailing list, as the spec should probably just be updated to make that second "MUST" a "SHOULD" to reflect real-world expectations. As long as a chain can be authenticated properly, the on-the-wire ordering isn't really important. There was previously talk of turning the "MAY" omit CA cert to a "SHOULD" or a "MUST", as well.