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/tls: handshake fails due to certificate parsing error #15407

Closed
marcelborrmann opened this issue Apr 22, 2016 · 10 comments
Closed

crypto/tls: handshake fails due to certificate parsing error #15407

marcelborrmann opened this issue Apr 22, 2016 · 10 comments

Comments

@marcelborrmann
Copy link

@marcelborrmann marcelborrmann commented Apr 22, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go 1.6.2 though this issue was also present on go version 1.3.x
  2. What operating system and processor architecture are you using (go env)?
    windows/amd64
  3. What did you do?
    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.

  1. What did you expect to see?
    I expected the missing seconds to be ignored and parsed as 0 instead.
  2. What did you see instead?
    The above error.
@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Apr 22, 2016

This is unlikely to be fixed until you provide the cert. Let us know when you have it.

@bradfitz bradfitz added this to the Unplanned milestone Apr 22, 2016
@bradfitz bradfitz changed the title TLS Handshake fails due to certificate parsing error crypto/tls: handshake fails due to certificate parsing error Apr 22, 2016
@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Jun 29, 2016

@marcelborrmann, can you attach the certificate?

/cc @agl

@agl

This comment has been minimized.

Copy link
Contributor

@agl agl commented Jun 30, 2016

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)"

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Jun 30, 2016

Thanks, @agl. Closing for now.

@bradfitz bradfitz closed this Jun 30, 2016
@dalini

This comment has been minimized.

Copy link

@dalini dalini commented Jul 1, 2016

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?

@dalini

This comment has been minimized.

Copy link

@dalini dalini commented Jul 1, 2016

So the timestamp of the certificate in quest - shown by openssl -text looks like this:

Validity
Not Before: Aug 14 10:28:47 2015 GMT
Not After : Aug 13 10:28:47 2017 GMT

asn1parse says:
145:d=2 hl=2 l= 30 cons: SEQUENCE
147:d=3 hl=2 l= 13 prim: UTCTIME :150814102847Z
162:d=3 hl=2 l= 13 prim: UTCTIME :170813102847Z

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?

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Jul 1, 2016

@dalini, you can email it to bradfitz at golang org

@dalini

This comment has been minimized.

Copy link

@dalini dalini commented Jul 4, 2016

done, looking forward to understand the issue of the certs in use or if there might be a change on golang instead.

@agl

This comment has been minimized.

Copy link
Contributor

@agl agl commented Jul 6, 2016

In this case, the problem is with root-ca.cer. In there we find:

  174:d=2  hl=2 l=  30 cons:   SEQUENCE          
  176:d=3  hl=2 l=  13 prim:    UTCTIME           :150814074318Z
  191:d=3  hl=2 l=  13 prim:    GENERALIZEDTIME   :203008210000Z

However, the spec says:

GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ)

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.

@dalini

This comment has been minimized.

Copy link

@dalini dalini commented Jul 6, 2016

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!

@golang golang locked and limited conversation to collaborators Jul 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.