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/tls: handshake fails due to certificate parsing error #15407
Comments
This is unlikely to be fixed until you provide the cert. Let us know when you have it. |
@marcelborrmann, can you attach the certificate? /cc @agl |
I suspect the certificate is invalid: https://tools.ietf.org/html/rfc5280#section-4.1.2.5: "UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ)" |
Thanks, @agl. Closing for now. |
Well sorry being late here - didn't manage it to answer earlier - the cert is a default as in no special settings - openssl created one - so I would expect to have valid timestamps. I've seen the timestamp discussion already but wondered if there are some settings to care of within openssl cnf files and commands to avoid this issue in golang? as the cert in quest das work properly with other applications and code based on different languages than golang. as the cert is an internal one - and might contain sensitive data - are there options to send it out of band e.g. not as a github issue comment? |
So the timestamp of the certificate in quest - shown by openssl -text looks like this: Validity asn1parse says: which looks valid to me according to the above stated definition should I create a new issue then? as the timestamp might not be the issue for this behaviour? |
@dalini, you can email it to bradfitz at golang org |
done, looking forward to understand the issue of the certs in use or if there might be a change on golang instead. |
In this case, the problem is with
However, the spec says:
And that GENERALIZEDTIME does not include seconds. However, all is not lost. Firstly, the TLS server should not be sending the root certificate in the first place so step one is to fix that. Then, when verifying the chain, you can use an altered root certificate with the seconds included. (I'll email you a fixed version of your root because playing with ASN.1 can be a pain.) The self-signature on the altered certificate will be invalid, of course, but the self-signature in a root certificate is just a placeholder anyway. |
Ahh too bad! I didn't check all the chain up. I would think that the server does not send the root-ca cert but the golang application might still use it from 'local' store so to say to validate the chain. But I'll check this too - what certs the server sends out - usually it should only be the cert itself as all systems have the root and the intermediary available locally. Well, so there seems to be an issue with the openssl config and the way the root-ca cert is selfsigned - I'll check this. Thanks for the ASN.1 playaround ;-). Will check this soon! |
Please answer these questions before submitting your issue. Thanks!
go version
)?go 1.6.2 though this issue was also present on go version 1.3.x
go env
)?windows/amd64
The SQL-Driver I'm using (https://github.com/denisenkom/go-mssqldb) tries to do a Handshake() with a MSSQL-Server, which then fails due to a parsing error:
"TLS Handshake failed: tls: failed to parse certificate from server:
parsing time "203008210000Z" as "20060102150405Z0700": cannot parse "Z" as
"05""
Brad Fitzpatrick suspected (Back when this was first encountered) that it has to do with missing seconds in the certificate. (https://groups.google.com/forum/#!topic/golang-dev/5A3QbXn2cRU)
I can not provide a sample certificate as of yet, but I will try to provide one at a later point. I suspect that reproducing this problem with the information given should be possible, though.
I expected the missing seconds to be ignored and parsed as 0 instead.
The above error.
The text was updated successfully, but these errors were encountered: