crypto/x509: support SSL_CERT_FILE/DIR on Darwin and Windows

[rolandshoemaker]

On darwin systems we use the platform certificate verifier, instead of the native Go one, by default. The only time we don't do this is if GODEBUG=x509usefallbackroots=1 is set and x509.SetFallbackRoots has been called.

Using the system verifier relies on a program being able to access the trustd service (via the darwin APIs we call), which is a daemon which does all of the certificate verification work for us.

There are some scenarios where someone running a Go program may want to limit access to trustd (e.g. see anthropics/sandbox-runtime#118). In this scenario, the program cannot be directly mutated to change the verifier settings (e.g. by using x509.SetFallbackRoots) and may wish to choose which roots to trust using SSL_CERT_FILE.

Currently, we explicitly do not support SSL_CERT_FILE on darwin, and only support it on non-darwin unix's.

It may be reasonable to support this use-case, by falling back to the native Go verifier if SSL_CERT_FILE is set on darwin system.

This could cause breakage, as we explicitly document that SSL_CERT_FILE is not used on darwin systems by Go, but is used by other programs in the environment and is set. Adding support for SSL_CERT_FILE would thus result in a change in program behavior, as we would no longer use the platform verifier.

This could be remedied by introducing a new GODEBUG that tells the program to either use the value of SSL_CERT_FILE or ignore it (e.g. maintaining our existing behavior).

cc @golang/security @rsc

[gabyhelp]

Related Issues

• proposal: crypto/x509: allow user override of the system roots on all platforms #71924
• crypto/x509: documentation about SSL_CERT_FILE and SSL_CERT_DIR is incorrect #37907 (closed)
• crypto/x509: use platform verifier on Windows, macOS and iOS #46287 (closed)
• crypto/x509: parse macOS keychain policies instead of using verify-cert #24084 (closed)
• proposal: crypto/x509: support systemVerify with p11-kit #71799
• crypto/x509: honor OS X certificate trust settings #18141 (closed)
• Use environment variables for trusted certificate store #14310 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[FiloSottile]

I think this is a subset of #71924.

[rsc]

If #71924 wants to contemplate broader things that's fine, but the industry has standardized on SSL_CERT_FILE, and we should support that.

[aclements]

Proposal review discussion:

• We already support SSL_CERT_FILE and SSL_CERT_DIR on all of the Unixes except Darwin.
• If we support SSL_CERT_FILE, we should probably support SSL_CERT_DIR, too (unfortunately)
• The main drawback of this is that we currently document that we ignore SSL_CERT_FILE on Darwin. We'd add GODEBUG=x509sslcertoverrideplatform. It would default to 1, but could be set to 0 to revert to the current behavior on Darwin. On Linux, the platform verifier itself uses SSL_CERT_FILE, so this variable has no effect either way.

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[connorshea]

Speaking only as a user of Go binaries like gh and glab, not the Go language itself, this'd be a welcome change as it's the only significant problem I've run into while sandboxing my Claude Code instance :) The setting workaround in Claude Code is fine for now, but this'd be great to have fixed properly in Go itself. 🙇

[aclements]

Here's the proposal as I understand it:

Enable support for SSL_CERT_FILE and SSL_CERT_DIR on Darwin, matching all other Unixes. If either is set, the Go library bypasses the platform verifier.

Add a GODEBUG called x509sslcertoverrideplatform, defaulting to 1. If set to 0 on Darwin, we would ignore SSL_CERT_FILE and SSL_CERT_DIR (reverting to pre-Go 1.27 behavior). On Linux, the platform verifier itself uses SSL_CERT_FILE, so this variable has no effect either way.

Question:

If building with a pre-Go 1.27 language version, should x509sslcertoverrideplatform default to 0 (old/compatible behavior)?