-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
cmd/go, crypto/x509: go mod tidy reports certificate expired on a non-expired certificate #60653
Comments
can you show the entire certificate? |
Ofcourse, here is the (slightly redacted) certificate.
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
I don't think we've been given enough information to identify the issue. |
cc @golang/security |
No, the certificate in #60653 (comment) is the certificate corresponding to the precertificate you found. It's pretty normal for CT logs to observe the precert and not the cert, especially for internal services. The question is where the 2013-07-26T11:03:57Z timestamp came from. @ysmilda are you sure the server is not serving different certificates to different connections? Is the issue intermittent or does it always reproduce? If you try to make a simple net/http connection without Thank you. |
@FiloSottile With |
@ysmilda is the timestamp returned always 2013-07-26T11:03:57Z? |
Yes, tested over multiple machines it always returns the same timestamp. The |
If you are on an enterprise network, it seems plausible that this could be a TLS middlebox trying to do something funky and failing, or some other class of TLS interception failure. Running the following program should give you an impression of the certificate chain being returned, I expect this is a local configuration issue, rather than a problem on our end, but if it turns up something strange I'd be interested in seeing it.
|
I would expect it to be an issue on our end, as it is a enterprise network where the gitlab instance is not accessible from outside. However there doesn't seem to be anything in our network that does non standard TLS handling, but I must admit my knowledge on the TLS subject is limited.
|
When setting the
I now see that The interesting part here is that here Chrome still reports a valid certificate while the above script reports the aforementioned |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
When running
go mod tidy
with an import from a local GitLab instance with a non-expired certificate it is reported as expired.The snippet above illustrates the basic setup used. When running
go mod tidy
it returns the following output:go mod tidy
OutputWhen checking the certificate via Chrome and by using
echo | openssl s_client -showcerts -servername localgitlabinstance -connect localgitlabinstance:443 2>/dev/null | openssl x509 -inform pem -noout -text
the certificate is valid from:When changing my system time to before
2013-07-26T11:03:57Z
I get the following output:go mod tidy
OutputIt then successfully retrieves the
Not Before
timestamp.The path taken from retrieving the certificate retrieval in the TLS handshake to verifying it seems pretty clear, so I'm uncertain where this discrepancy between the
crypto/x509
parsing and the other tooling comes from.The text was updated successfully, but these errors were encountered: