crypto/tls: handshake fails due to certificate parsing error

[marcelborrmann]

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 is unlikely to be fixed until you provide the cert. Let us know when you have it.

[bradfitz]

@marcelborrmann, can you attach the certificate?

/cc @agl

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

[bradfitz]

Thanks, @agl. Closing for now.

[dalini]

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]

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]

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

[dalini]

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

[agl]

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]

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!