#18508 (comment)

davecheney: @iamzhout it looks like your employer is MITM'ing your SSL communications.
Go get is just a wrapper over git, I recommend git cloning that repository directly.

@davecheney you're right, the https cert will be replaced over company policy, so ... but anyway, I think this should be quite common, maybe.

but the point is that there is no problem if I use git clone directly, if go get is 'just' a wrapper, I would expecte it to work fine also.

git clone -v https://gopkg.in/yaml.v2.git
Cloning into 'yaml.v2'...
POST git-upload-pack (290 bytes)
remote: Counting objects: 921, done.
remote: Total 921 (delta 0), reused 0 (delta 0), pack-reused 921
Receiving objects: 100% (921/921), 1.16 MiB | 0 bytes/s, done.
Resolving deltas: 100% (572/572), done.
Checking connectivity... done.

go get is not "just" a wrapper for git. one step is to invoke git but the first step is to fetch https://gopkg.in/yaml.v2.git to learn where that comes from. The certs that 'go get' is finding do not include the company MITM cert. On Linux the cert list is:

// Possible certificate files; stop after finding one.
var certFiles = []string{
        "/etc/ssl/certs/ca-certificates.crt",                // Debian/Ubuntu/Gentoo etc.
        "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
        "/etc/pki/tls/certs/ca-bundle.crt",                  // Fedora/RHEL 6
        "/etc/ssl/ca-bundle.pem",                            // OpenSUSE
        "/etc/pki/tls/cacert.pem",                           // OpenELEC
}

It sounds like whichever of those files is on your system does not include the company CA. If it did, go get would succeed at the https fetch.

Actually, I see your $https_proxy above now. I don't know why go get would not be using that.

@rsc, cmd/go/http.go doesn't set ProxyFromEnvironment:

// impatientInsecureHTTPClient is used in -insecure mode,                                                                                    
// when we're connecting to https servers that might not be there                                                                            
// or might be using self-signed certificates.                                                                                               
var impatientInsecureHTTPClient = &http.Client{
        Timeout: 5 * time.Second,
        Transport: &http.Transport{
                TLSClientConfig: &tls.Config{
                        InsecureSkipVerify: true,
                },
        },
}       

That is, we have different proxy behavior in --insecure mode. I'll send a CL.

CL https://golang.org/cl/34818 mentions this issue.

Thanks @bradfitz for your quick fix.

While seems this fix only takes effect when -insecure flag provided? Doesn't this already work fine as I mentioned earlier that if giving -insecure option, the go get is ok?

I also have tested using the latest nightly build(?),

➜ /usr/local >go get -u -v -insecure gopkg.in/yaml.v2
Fetching https://gopkg.in/yaml.v2?go-get=1
https fetch failed: Get https://gopkg.in/yaml.v2?go-get=1: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Fetching http://gopkg.in/yaml.v2?go-get=1
Parsing meta tags from http://gopkg.in/yaml.v2?go-get=1 (status code 200)
get "gopkg.in/yaml.v2": found meta tag main.metaImport{Prefix:"gopkg.in/yaml.v2", VCS:"git", RepoRoot:"https://gopkg.in/yaml.v2"} at http://gopkg.in/yaml.v2?go-get=1
gopkg.in/yaml.v2 (download)
gopkg.in/yaml.v2
➜ /usr/local >go get -u -v gopkg.in/yaml.v2
Fetching https://gopkg.in/yaml.v2?go-get=1
https fetch failed: Get https://gopkg.in/yaml.v2?go-get=1: x509: certificate signed by unknown authority
gopkg.in/yaml.v2 (download)
➜ /usr/local >go version
go version 1.7rc1-nightly-a1110c39301b21471c27dad0e50cdbe499587fc8 linux/amd64

Does above log means go get -u -v gopkg.in/yaml.v2 is successful?

@rsc

It sounds like whichever of those files is on your system does not include the company CA. If it did, go get would succeed at the https fetch.

Actually I have already imported related certs into /etc/ssl/certs/ca-certificates.crt before submitting this issue, and unfortunately without luck. Below is the steps what I do:

1. open firefox, and use the same proxy above: http://my-corporate-proxy:8080
2. navigate to "https://gopkg.in/yaml.v2", click upper left lock icon, and open "View Certificate"
3. export the cert to /usr/local/share/ca-certificates
4. run update-ca-certificates, and double check that /etc/ssl/certs/ca-certificates.crt does include this new cert

So seems go get doesn't recognise local certs? and still reports "certificate signed by unknown authority".

@iamzhout, I don't think your nightly build was new enough. The bug fix was that -insecure mode previously did not respect your $HTTP_PROXY (etc) environment variables. Now it does.

@bradfitz I have built and tested latest golang code on master branch. As the fix says it will only take effect when using -insecure option with go get, which doesn't resolve my problem :(

@rsc I just digged a little bit deeper to find out the root cause. It seems that the original gopkg site cert will be replaced by a dynamically generated cert which, instead of a constant one, will be different every single minute in validation start/end time fields, as shown in below picture.

So it turns out that the problem is not in golang's X509 verification algorithm which will do byte comparison using bytes.Equal, but the cert itslef.

I will try to contact IT guys in company to see if the troublesome dynamic cert policy could be changed, though most probably not.

Thanks for your help.

Okay, closing.

Just to update that I missed to understand https cert quite well, and added leaf cert previously, not company cert which @rsc already pointed out . After I added the root company cert, problem got resolved perfectly.