TLS connection to web service is failing with EOF in the client handshake

4,103 views
Skip to first unread message

rob....@gmail.com

unread,
Dec 2, 2015, 4:33:51 PM12/2/15
to golang-nuts
I'm trying to connect to a web service hosted by a third party using mutual TLS. Here is the simple test case I am trying:


I am able to connect to the same web service with the same parameters for key, cert, etc using curl:

curl --cacert /home/nifi/robtest/nexusproxy/guard_ca.pem --cert /path/to/public_crt.pem --key /path/to/private_key.pem https://some.server.com:8000/some/path

The go test case fails with an EOF error. I've traced the error to this line in the tls client handshake:


This section https://github.com/golang/go/blob/go1.5.1/src/crypto/tls/conn.go#L541-L546 would seem to suggest that an EOF is expected in some cases but there doesn't appear to be any code to handle such a case.

Unfortunately the folks responsible for this web service don't seem to know much about it - about all I know is that its running Jetty. 

Any insight into why it would work with curl, but not go?

Thanks!

Rob.

Dave Cheney

unread,
Dec 2, 2015, 4:48:30 PM12/2/15
to golang-nuts
Does this service require TLS client authentication? What happens if you hit the service with a browser ? Does it prompt you for authentication, and if so, what type?

rob....@gmail.com

unread,
Dec 2, 2015, 5:03:10 PM12/2/15
to golang-nuts
It does require TLS authentication. Attempting to connect to it with curl without the cert and key (or a cert/key that it doesn't recognize) will fail to establish a connection - that is you don't even get an http error. It appears they're using whatever their equivalent is to tls.RequireAndVerifyClientCert. I am unable to hit the url with a browser - firewall rules prevent me from connecting to it from anything other than a particular application server.

Dave Cheney

unread,
Dec 2, 2015, 11:12:28 PM12/2/15
to golang-nuts
I believe that the go TLS package does not support client side certificate authentication.

Alex Skinner

unread,
Dec 3, 2015, 12:31:32 AM12/3/15
to golang-nuts
The TLS package certainly does support this.  I'd want AGL et al to take a look, but based on the source, I think it may warrant a bug report even if it's only to clarify wording.  It clearly states it cannot make io.EOF an error, then on the next line proceeds to set it as an error (since it would fail net.Error assertion) and return.

Thanks,
Alex

Wim Lewis

unread,
Dec 3, 2015, 12:42:12 AM12/3/15
to golang-nuts

On Dec 2, 2015, at 8:12 PM, Dave Cheney <da...@cheney.net> wrote:
> I believe that the go TLS package does not support client side certificate authentication.

IIRC, if you place the result of tls.LoadX509KeyPair in tls.Config.Certificates before calling tls.Dial, it will be offered to the server as a client certificate.


Dave Cheney

unread,
Dec 3, 2015, 12:59:08 AM12/3/15
to golang-nuts
Thanks for correcting me Alex. I hope we're talking about the same thing 'cos Canonical have been carrying a hacked copy of the 1.2 http package with an old patch to enable this for several years, it would be excellent to be able to dump this.

rob....@gmail.com

unread,
Dec 7, 2015, 2:21:39 PM12/7/15
to golang-nuts, rob....@gmail.com
Thank you everyone for your replies. Per Alex's suggestion I opened up an issue:


I apologize for taking so long to reply - I was out the rest of last week. I probably should have waited until today to post the question. Thanks again!

Nick Craig-Wood

unread,
Dec 8, 2015, 10:21:05 AM12/8/15
to rob....@gmail.com, golang-nuts
Here is a complete example of how to do client side certs on server and
client in Go.

https://gist.github.com/ncw/9253562

I haven't checked your code, but you might find the above interesting.
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com
> <mailto:golang-nuts...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick
Reply all
Reply to author
Forward
0 new messages