crypto/x509: come up with better solution for testing platform verifiers

[rolandshoemaker]

As evidenced by #52094 and #51599, there are issues with relying on third-party services for testing the platform verifier implementations. Ideally we'd run these tests entirely locally, but this requires mutating the trust store on the systems being tested.

While we absolutely cannot start inserting arbitrary certificates into the trust stores of developers, it may be reasonable to do this on the trybots (although there will still be some gaps here, since user added roots are always going to be treated somewhat differently than roots the system chooses to trust.)

We should still have some kind of local testing that doesn't rely on trust store mutation though, perhaps just retaining the existing badssl.com based tests but gating them behind a flag?

[gopherbot]

Change https://go.dev/cl/397694 mentions this issue: crypto/x509: local platform verifier tests on trybots

[gopherbot]

Change https://go.dev/cl/405914 mentions this issue: crypto/x509: attempt to prime windows root pool before hybrid test

[bcmills]

2022-06-06T18:37:38-fc97075/windows-amd64-longtest has another failure due to badssl.com having a cert that is bad in the wrong kind of way:

--- FAIL: TestPlatformVerifier (15.19s)
    --- FAIL: TestPlatformVerifier/wrong_host_for_leaf (15.11s)
        root_windows_test.go:109: unexpected verification error: got "x509: certificate has expired or is not yet valid: ", want "x509: certificate is valid for *.badssl.com, badssl.com, not wrong.host.badssl.com"
FAIL
FAIL	crypto/x509	32.031s

[rolandshoemaker]

The least worst option I can think of: we insert a static certificate into the builder images for macos and windows, and use it to sign local certificates. For testing on local systems, we provide a very scary flag the user can pass that will generate an ephemeral key/cert pair and attempt to insert it into the trust store for the duration of the testing, removing it when done.

This should get us the best of both worlds, with only minor pain.

[rolandshoemaker]

Plan is: basically above. We'll generate a highly constrained root, which will be used for testing. Rather than a flag that lets the user insert it into their own pool, we'll simply add it to the tree and allow users to insert it into their own trust pool if they wish.

We'll add a wrapper to the platform tests which decide whether or not to run them based on the detectable presence of the constraint root, this way they'll run on developers systems who want to test them, and it'll require at least some knowledge of trust stores in order to add it (rather than simply passing a flag and not really knowing what you're getting yourself into).

I'll implement the sniffing + tests etc first, and once that has landed and we have a root in the tree, we'll pass this on to the release team to add to the builder images.

[gopherbot]

Change https://go.dev/cl/488855 mentions this issue: crypto/x509: use synthetic root for platform testing