go TLS validates a certificate where curl / openssl does not

[mrkhi...@gmail.com]

Hi,

Just wondering if anyone could help me to understand if this is expected behaviour / valid tls behaviour. I am using the go net/http client to connect to the server: https://user.aylanetworks.com

The certificate for this server shows the following when inspected with openssl:

Certificate chain

 0 s:/OU=Domain Control Validated/CN=*.aylanetworks.com

   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287

 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287

   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=in...@valicert.com

I'm running the client on Ubuntu 14.04.2 LTS and it has the following certificates installed:

Go_Daddy_Class_2_CA.pem

Go_Daddy_Root_Certificate_Authority_-_G2.pem

but no ValiCert certificates installed.

curl and openssl both give the error "unable to get local issuer certificate" when I try to connect to https://user.aylanetworks.com, yet the golang http client connects to that same url without complaining. Is it the case that the certificate validation only goes so far as '1' in the certificate chain, finds that it is validated by the GoDaddy root cert and then decides it doesn't need to validate '2' in the chain?

Is openssl / curl more secure for having done the extra validation step?

(FWIW, I can confirm that I have previously made the curl error go away by installing the ValiCert root certificate on the client)

Thanks,

Mark

[Paul van Brouwershaven]

Your certificate is installed 'correctly' (https://www.ssllabs.com/ssltest/analyze.html?d=user.aylanetworks.com&latest) but your openssl and curl commands don't include a root store to verify the chain.

GO is using your system root store so can validate the chain.

See also:

https://golang.org/src/crypto/x509/root_unix.go

[Mark Hingston]

Sorry for the late reply - I didn't seem to get a notification when my post was approved by a moderator nor when it was replied to.

I'm not convinced that what you have mentioned is the reason that I see an error in curl. If I run curl with -v then I see that it prints:

CApath: /etc/ssl/certs

and if I add just the Valicert root certificate to /etc/ssl/certs then the error goes away. So I'm pretty confident that curl is using the store at /etc/ssl/certs

I'm also not seeing any errors in curl when I connect to other https urls without specifying any specific root store.

Also, I'm pretty confident that go also uses the root store at /etc/ssl/certs. I guess mainly from looking here:

https://golang.org/src/crypto/x509/root_unix.go

Additionally, from having had a bit of a look at:

https://golang.org/src/crypto/x509/verify.go

I am pretty confident that what go does is when it finds that (1) in the certificate chain can be validated against a cert in the root store, it exits and doesn't check (2) against the root store.

Please correct me if I'm wrong. But assuming I'm not wrong, my question is about the security implications of validating or not validating (2).

Thanks.

Mark

[and...@yasinsky.com]

Curl is rather lax to ssl validation.

if you want to mimic curl  in net.http set:

Transport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

[Matt Harden]

curl is only lax on validation if the --insecure option, or equivalent, is given.

--
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.
For more options, visit https://groups.google.com/d/optout.

[ma...@homeboy.com]

Just to be clear, I'm definitely not invoking curl with --insecure

And for that matter, what I'm seeing is that curl is showing an error where go is not. So if either is being more lax, i would have said it was go

Thanks

Mark