An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted

An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-L81 https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it. in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072 https://twitter.com/benmmurphy/status/613733887211139072) 'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.' and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this: RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE | V VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set) | V EVIL CERTIFICATE SIGNED BY PREVIOUS CERT