Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: TestHybridPool failures on Windows with x509: certificate signed by unknown authority #51599

Open
bcmills opened this issue Mar 10, 2022 · 7 comments
Assignees
Labels
NeedsInvestigation OS-Windows release-blocker
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 10, 2022

--- FAIL: TestHybridPool (15.02s)
    hybrid_pool_test.go:66: verification failed for google.com chain (empty pool): x509: certificate signed by unknown authority
FAIL
FAIL	crypto/x509	31.546s

greplogs --dashboard -md -l -e 'FAIL: TestHybridPool'

2022-03-10T16:06:29-1cf6770/windows-amd64-longtest

(attn @golang/security for triage)

@bcmills bcmills added NeedsInvestigation release-blocker labels Mar 10, 2022
@bcmills bcmills added this to the Go1.19 milestone Mar 10, 2022
@rolandshoemaker rolandshoemaker self-assigned this Mar 18, 2022
@bcmills
Copy link
Member Author

@bcmills bcmills commented Mar 30, 2022

greplogs --dashboard -md -l -e 'FAIL: TestHybridPool' --since=2022-03-11

2022-03-24T17:50:47-b95d332/windows-amd64-longtest

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 2, 2022

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

@bcmills bcmills changed the title crypto/x509: TestHybridPool failure with x509: certificate signed by unknown authority crypto/x509: TestHybridPool failures on Windows with x509: certificate signed by unknown authority May 12, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented May 12, 2022

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

gopherbot pushed a commit that referenced this issue May 12, 2022
In TestHybridPool attempt to prime to the windows root pool before
the real test actually happens. This is a bit of a band-aid, with
a better long term solution discussed in #52108.

Updates #51599

Change-Id: I406add8d9cd9e3fae37bfc20b97f5479c10a52c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/405914
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
@bcmills
Copy link
Member Author

@bcmills bcmills commented May 13, 2022

Due to #52591 the windows-amd64-longtest builders have only completed one run since the above CL went in, but so far they haven't failed with this mode again.

Marking WaitingForInfo to remind us to recheck the fix after more test runs have completed.

@bcmills bcmills added the WaitingForInfo label May 13, 2022
@bcmills
Copy link
Member Author

@bcmills bcmills commented May 18, 2022

There was a rash of failures yesterday — again all on Windows — but the failure mode is slightly different. 🤔

--- FAIL: TestPlatformVerifier (0.08s)
    --- FAIL: TestPlatformVerifier/wrong_host_for_leaf (0.02s)
        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	1.942s

greplogs -l -e 'FAIL: TestPlatformVerifier .*(?:\n[ ]{4}.*)*badssl\.com' --since=2022-05-13
2022-05-17T18:55:46-668041e/windows-amd64-longtest
2022-05-17T18:19:34-076039a/windows-amd64-longtest
2022-05-17T18:13:13-afd181c/windows-amd64-longtest
2022-05-17T17:54:33-cc4957a/windows-amd64-longtest
2022-05-17T17:29:34-cf5fa2b/windows-amd64-longtest
2022-05-17T16:09:37-770e0e5/windows-amd64-longtest
2022-05-17T14:39:18-cf7ec0f/windows-amd64-longtest

@bcmills bcmills removed the WaitingForInfo label May 18, 2022
@bcmills
Copy link
Member Author

@bcmills bcmills commented May 18, 2022

I think the above failures may have been due to a misconfiguration of the badssl.com service itself, although it does seem strange to me that it only failed on Windows.

I wonder if the Windows root store ended up pulling in one of the badssl.com certificates but not the others, causing the error to be reported from the wrong certificate? Or maybe the badssl.com service itself was misconfigured for a while...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation OS-Windows release-blocker
Projects
None yet
Development

No branches or pull requests

3 participants