#12000 Artifact fails to download with `invalid certificate: BadDER` Issue created by cjntaylor My company uses SSL inspection as part of its security envelope. This system requires the equivalent of a self-signed intermediate certificate to be added to the system certificate store as a root certificate authority in order for any SSL based connection to function. Any SSL based connection will be intercepted and rewritten; the new connection will be signed by this CA instead of its original authority and packets will be rewritten to match. I've been unable to use pants in this context, which, when attempting to download it's artifacts, reports the following error:

Exception: Error downloading file: error sending request for url (<https://github.com/pantsbuild/pex/releases/download/v2.1.35/pex>): error trying to connect: invalid certificate: BadDER

With the help of some very nice folks on slack, we've already traced this issue to the rust part of the system, in the

rustls

crate used by

reqwest

. I've attatched the relevant logs, and I'd be happy to generate / capture anything else you'd find helpful. Long story short, it looks like I'm running into the issue reported here: rustls/rustls#127. Rustls diverges from openssl behaviour; when attempting to process the certificate, it attempts to read the

subjectAltName

from it. In my case, the final dynamic inspection certificate has one, but the two previous signing CA certificates in chain only have a common name. Since this extension is missing, when

rustls

attempts to read the field, it fails, implodes, and the request fails with the above error (or so we currently think). The certificates probably should have subjectAltName extensions set. However, they're generated dynamically, and not really in my control - they're handled at a much higher level by a different department in a large organization; it will take months if not years to get something like that fixed (if I even can get someone to care). Most people don't run into this issue because openssl is more permissive in this case and doesn't fault when the subjectAltName is missing. So if it's possible, it would be really helpful if a pants side fix could be implemented to address this. SSL Intercept systems like this are becoming increasingly common at large corporations, to prevent in-network malicious actors from messaging home in SSL packets. I promise you this isn't a one-off issue. I'm a full stack developer, and normally I'd just figure out the solution, and issue an MR with a proposed fix (since this affects me, it seems like the right thing to do). However, I'm not at all familiar with rust, and this is a security issue - I'm not the person you want poking around in the source code trying to fix this. I'd be happy to help in any other way I can, and I can test / debug / log anything that would be helpful. I have captured the SSL exchange at the packet level, and I have confirmed that the certificates in the exchange are fully formed and valid. As the certificates are authorities, and could be used for signing purposes, I can't actually share any of these, but, I can report back any information that would be helpful, or try to capture any details that might be useful. Thanks in advance for any help 😄 20210501194000_pants_debug.log pantsbuild/pants