Golang panic in tls conn Read - only on linux?

I'm using golang crypto/tls to process a custom line-oriented message protocol.

This approach works fine on windows:

var fullBuffer string
for {
	// If we're not connected, attempt reconnect
	if this.conn == nil {
		if this.IsSecure() {
			this.conn, err = tls.Dial("tcp", this.GetHostOnly(), nil)
		} else {
			this.conn, err = net.Dial("tcp", this.GetHostOnly())
		}
		if err == nil {
			// log and continue
		}
	}
	// Read from socket into our local buffer (blocking)
	if this.conn != nil {
		readBuff := make([]byte, 4096)
		nbytes, err = this.conn.Read(readBuff)
		if nbytes > 0 {
			fullBuffer += string(readBuff[0:nbytes])
		}
	}

Pretty straightforward - and it works fine on win64.

But when i try to run it on Linux (debian 8 - both i386 and amd64 - both golang 1.5 native and 1.6 crosscompiled from windows) i get the following panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x4ec8b4]
goroutine 8 [running]:
panic(0x8237780, 0x18522030)
    C:/Go/src/runtime/panic.go:464 +0x326
crypto/tls.(*Conn).Handshake(0x0, 0x0, 0x0)
    C:/Go/src/crypto/tls/conn.go:1023 +0x198
crypto/tls.(*Conn).Read(0x0, 0x18597000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    C:/Go/src/crypto/tls/conn.go:922 +0x5e
mylib.(*MyConnection).worker(0x18512480)
    C:/gopath/src/mylib/mylib.go:342 +0x200

The Read call is failing because it's somehow passing nil to the TLS handshake.

What's going wrong here?

And, why is the problem isolated to linux?

OK, linux builds are producing the error x509: certificate signed by unknown authority.

But

• the certificate is valid

  • crypto/x509/root_unix.go looks in /etc/ssl/certs which is world-readable
  • but openssl s_client is hanging on -showcerts -verify, pointing to some issue with my OS network configuration

• for some reason the if block below is being entered regardless of the error

  • but i was storing it as a net.Conn instead of a pointer, so it's not nil-able.

Calling this solved, sorry for the noise. Hopefully this debugging story helps someone else in the future