Add initial new_with_extra_roots testing

[complexspaces]

This PR begins adding tests for the Verifier::new_with_extra_roots extension currently available on all platforms except Android.

It adds two "simple" cases to cover the known-so-far/common cases we want and expect manually added, non-public roots to behave as trustworthy. I had to modify the ca.go generation script to support producing selfsigned certificates that operate on their own without an actual chain.

The second test currently doesn't run on Windows but can be enabled at the same time #215 lands. I validated this locally by manually cherry-picking over the commit:

cargo test with_extra_roots
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running unittests src\lib.rs (target\debug\deps\rustls_platform_verifier-2bee31e54d3b8ab4.exe)

running 2 tests
test tests::verification_mock::test_selfsigned_cert_with_extra_roots ... ok
test tests::verification_mock::test_chain_signed_with_extra_roots ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 26 filtered out; finished in 0.02s

[complexspaces]

It looks like the UNIX testing ran into rustls/webpki#205 where the behavior desired in #214 isn't supported. I'm not sure yet what to do about that. macOS and Windows are passing, as expected.

[cstkingkey]

As said in rustls/webpki#205 (comment), self-signed certificates differ in ca parameter. Both cases shall be tested.

openssl doc

A CA certificate must include the basicConstraints name with the CA parameter set to TRUE. An end-user certificate must either have CA:FALSE or omit the extension entirely.

[complexspaces]

I swear I had something close to that locally earlier today but macOS wasn't happy. I might have messed up my Go code though and made the generator output wrong so I'll try again. We agree both cases should be tested, I guess one just might need skipped on the generic UNIX backend?

[djc]

I swear I had something close to that locally earlier today but macOS wasn't happy. I might have messed up my Go code though and made the generator output wrong so I'll try again. We agree both cases should be tested, I guess one just might need skipped on the generic UNIX backend?

Not completely sure I understand what you mean.

webpki in my understanding does not allow verifications where the trust root is self-signed, and is also the entity being verified. In my mind we probably should avoid (to the extent that we can) allowing this on other platforms, too? So I think we should test it but make sure it fails.

[cstkingkey]

@djc @complexspaces
Under Linux, a single self-signed cert with ca:false is verified.
Under macOS, the same cert get Err(InvalidCertificate(Other(OtherError("“foo” certificate is not standards compliant: -67901")))).
According to the error code, the error seems to be "The validity period in the certificate exceeds the maximum allowed". A new cert with same configuration except with 396 days validity period can be verified.
For single self-signed cert with ca:true, windows and macOS accept it as valid. The macOS has error code "-67902 | The verified certificate is a CA rather than an end-entity" according google search results, but the test did not run into it.
It behaves differently under different platforms. This crate shall define its standard for such cases. But I think it should give the consumers options to configure its behavior, for example, to ensure backward compatibility.

[complexspaces]

for example, to ensure backward compatibility.

Yeah, it would be nice not to break any existing users with these kind of certificates.

This crate shall define its standard for such cases. But I think it should give the consumers options to configure its behavior.

We definitely don't have a shortage of platform-specific quirks today but part of me wants to try avoiding more. I guess there's no naming conflict at least between ca: false and the function being called new_with_extra_roots: A self-signed entity certificate is its own root.

Not completely sure I understand what you mean.
...
In my mind we probably should avoid (to the extent that we can) allowing this on other platforms, too?

@djc I agree on that path 👍. Sorry if my first message was confusing though, I was just trying to say that I tried a different root CA vs what is checked into this branch on macOS and received a "not valid" error back from the platform.

ca: false seems like a valid use case that can work on all platforms, but we would need to see if if there's a way to keep the ca:true case from passing on Windows or at least appearing to the end user so the behavior is more consistent and easily testable. Two ideas come to mind:

• Look at the returned status information more deeply to see if we can detect the ca: true single-certificate chain case and explicitly bail out.
• Use existing Win32 functions to return various X.509 fields back to us to search for the case ourselves right after building a chain with the extra roots. Perhaps through the CERT_EXTENSION fields stored on CERT_INFO?

[cstkingkey]

@complexspaces ca:true is passing on macOS too.