Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: add standard SSL_CERT_DIR locations #14311

Closed
raspy opened this issue Feb 12, 2016 · 6 comments
Closed

crypto/x509: add standard SSL_CERT_DIR locations #14311

raspy opened this issue Feb 12, 2016 · 6 comments
Assignees
Milestone

Comments

@raspy
Copy link

@raspy raspy commented Feb 12, 2016

crypto/x509/root_linux.go defines some standard certificate bundles locations, but root_unix.go defines only one single certificate directory. This should be consistent with OpenSSL design of system certificates:

  • read certificate bundle from OPENSSL_DIR/certs.pem
  • read all certificates from OPENSSL_DIR/certs directory

Currently #1 is fulfilled with root_linux.go, but #2 is missing; so e.g. on Fedora/RHEL /etc/pki/tls/certs/ca-bundle.crt is read, but directory /etc/pki/tls/certs is not searched.

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Feb 12, 2016
@ianlancetaylor ianlancetaylor changed the title Add standard SSL_CERT_DIR locations crypto/x509: add standard SSL_CERT_DIR locations Feb 12, 2016
@minux
Copy link
Member

@minux minux commented Feb 15, 2016

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 5, 2016

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

@knweiss
Copy link

@knweiss knweiss commented Sep 23, 2016

@raspy root_unix.go defines only one single certificate file for each distribution.

I also just ran into this problem on an old openSUSE 13.1 system where root_unix.go of go1.7.1 uses /etc/ssl/ca-bundle.pem which is a symlink to /var/lib/ca-certificates/ca-bundle.pem. The file has this header:

#
# automatically created by /usr/lib/ca-certificates/update.d/certbundle.run. Do not edit!
#
# Use of this file is deprecated and should only be used as last
# resort by applications that do not support p11-kit or reading /etc/ssl/certs.
# You should avoid hardcoding any paths in applications anyways though. Use
# functions that know the operating system defaults instead:
#
# - openssl: SSL_CTX_set_default_verify_paths()
# - gnutls: gnutls_certificate_set_x509_system_trust(cred)

Unfortunately, on this system nobody ever executed /usr/lib/ca-certificates/update.d/certbundle.run and (apart from the header) the file was empty and thus certificate validation failed (e.g. go get).

Executing the script fixes the problem but not everyone was happy with the solution and commented that Go shouldn't rely on this deprecated file on openSUSE.

@knweiss
Copy link

@knweiss knweiss commented Sep 23, 2016

Hm, I just noticed #12139 which seems to provide support for the /etc/ssl/certs/ directory.

@knweiss
Copy link

@knweiss knweiss commented Sep 23, 2016

AFAICS the problem seems to be that loadSystemRoots() returns if it can successfully open the (in our case empty!) /etc/ssl/ca-bundle.pem. It does not continue with scanning the certDirectories i.e. /etc/ssl/certs/:

func loadSystemRoots() (*CertPool, error) {
        roots := NewCertPool()
        var firstErr error
        for _, file := range certFiles {
                data, err := ioutil.ReadFile(file)
                if err == nil {
                        roots.AppendCertsFromPEM(data)
                        return roots, nil
                }
@quentinmit quentinmit added the NeedsFix label Oct 5, 2016
@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 3, 2016
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 2, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.