Fix TLS certificate validation in Go and net/http

1. Search for InsecureSkipVerify: true, VerifyPeerCertificate and VerifyConnection callbacks, RootCAs built from x509.SystemCertPool() plus extra certificates, and every http.Transport, tls.Dial and grpc credential that takes a tls.Config.
2. For a public service, delete InsecureSkipVerify and leave RootCAs nil, which uses the host's root CAs.
3. For a private service, read its CA bundle (PEM), add it to x509.NewCertPool() and fail if AppendCertsFromPEM returns false, which means no certificate was found. Set the pool as RootCAs on that one client's Transport.
4. Leave ServerName empty for net/http, which sets it from the URL's host. If you connect by IP address or an alias, set ServerName to the name the certificate carries, or reissue the certificate with that name.
5. Set MinVersion: tls.VersionTLS12 (or TLS 1.3) so the floor is in the code, not in the defaults.
6. If you need an extra check, such as pinning a key, keep normal verification on and add it in VerifyConnection, which runs after it and on resumed connections.

The three implementations share one API and one test suite; only the code below changes. The tests load the one that IMPL names.

func (Vulnerable) TLSConfig(caPEM []byte) (*tls.Config, error) {
	// Staging failed with "x509: certificate signed by unknown authority", so verification
	// was turned off. This is the bug: every certificate is accepted, for any host name.
	return &tls.Config{InsecureSkipVerify: true}, nil
}

func (Fixed) TLSConfig(caPEM []byte) (*tls.Config, error) {
	// A new pool, not x509.SystemCertPool(): no public CA, and nothing that SSL_CERT_FILE or
	// SSL_CERT_DIR adds to the system pool, can vouch for the partner.
	roots := x509.NewCertPool()
	if !roots.AppendCertsFromPEM(caPEM) {
		return nil, errors.New("the partner CA file holds no PEM certificate")
	}
	return &tls.Config{
		RootCAs:    roots,
		MinVersion: tls.VersionTLS12,
		// InsecureSkipVerify stays false. ServerName stays empty, so net/http sets it to the
		// URL's host and crypto/tls checks it against the certificate's DNS names.
	}, nil
}

func (Wrong) TLSConfig(caPEM []byte) (*tls.Config, error) {
	roots := x509.NewCertPool()
	if !roots.AppendCertsFromPEM(caPEM) {
		return nil, errors.New("the partner CA file holds no PEM certificate")
	}
	return &tls.Config{
		MinVersion: tls.VersionTLS12,
		// We reach the partner through an internal alias, so every call failed with
		// "x509: certificate is valid for ..., not ...". Verifying the chain ourselves,
		// without DNSName, made the error go away.
		InsecureSkipVerify: true,
		VerifyConnection: func(cs tls.ConnectionState) error {
			opts := x509.VerifyOptions{Roots: roots, Intermediates: x509.NewCertPool()}
			for _, cert := range cs.PeerCertificates[1:] {
				opts.Intermediates.AddCert(cert)
			}
			_, err := cs.PeerCertificates[0].Verify(opts)
			return err
		},
	}, nil
}

The exploit tests send the attack and check that it fails; functional tests next to them keep ordinary requests working, so a fix that rejects everything fails too.

// Each server below answers at api.partner.test but must not be trusted. The client has to
// refuse the TLS handshake before it sends the request carrying the bearer token.

func TestExploitASelfSignedCertificateForThePartnerHostNameIsRefused(t *testing.T) {
	assertRefused(t, "selfSigned")
}

func TestExploitACertificateFromTheTrustedCAForAnotherHostNameIsRefused(t *testing.T) {
	assertRefused(t, "otherHost")
}

func TestExploitACertificateFromAnUnknownCANamedLikeTheTrustedCAIsRefused(t *testing.T) {
	assertRefused(t, "rogueCa")
}

func TestExploitAnExpiredCertificateFromTheTrustedCAIsRefused(t *testing.T) {
	assertRefused(t, "expired")
}

• InsecureSkipVerify turns off the chain check and the host name check together. The crypto/tls example that pairs it with VerifyConnection rebuilds both with x509.VerifyOptions; leave out DNSName, as wrong.go does, and any certificate the CA issued for any host passes.
• VerifyPeerCertificate is not called on resumed connections, so a check that replaces normal verification there can be skipped. VerifyConnection runs for every connection, including resumptions (gosec G123 looks for the first pattern).
• x509.SystemCertPool() plus AppendCertsFromPEM trusts every public CA, as well as the partner's, to vouch for the partner, and SSL_CERT_FILE and SSL_CERT_DIR change what SystemCertPool returns (on macOS and Windows too since Go 1.27). Use a new pool for a private service.
• Go ignores the certificate's Common Name and checks only its DNS and IP subject alternative names, so a certificate without a matching SAN fails. Reissue it rather than turn the check off.
• Go has no process-wide switch like NODE_TLS_REJECT_UNAUTHORIZED: verification is off only where code sets InsecureSkipVerify. Search vendored and internal packages that build their own http.Client too.
• CodeQL's go/disabled-certificate-check skips functions and variables whose names contain verif, validat or trust, so do not rely on it alone.

1. Run the tests in all three modes: IMPL=fixed must pass; IMPL=vulnerable and IMPL=wrong must fail (node ../../run-all.mjs tls-certificate-validation/go-nethttp does this for you, in Docker if you do not have Go).
2. The exploit tests present a self-signed certificate for the right name, a certificate from the trusted CA for another name, one from an unknown CA named like the trusted CA, and an expired one; each must end in 502 with no request, and so no bearer token, reaching the server.
3. Run gosec ./... and semgrep --config r/problem-based-packs.insecure-transport.go-stdlib.bypass-tls-verification.bypass-tls-verification .; expect findings only in impl/vulnerable.go and impl/wrong.go. Neither sees a missing host name check that does not set InsecureSkipVerify.
4. Against your own service, point the client at a server with a self-signed certificate for the real name and at one with a valid certificate for a different name (openssl s_server will do). Both handshakes must fail.

What each rule reported when it was run on this card's code, or what its source shows it covers where it was not run. A rule that exists for the weakness does not always catch it.

Download the project, install its dependencies once (this step needs the network), then run the tests against each implementation from the tls-certificate-validation/go-nethttpfolder.

go mod download
go build ./... tool

# Expected: every test passes
IMPL=fixed go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...

# Expected: an exploit test fails
IMPL=vulnerable go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...

# Expected: a test fails
IMPL=wrong go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...

Without Go installed, run the same commands with Docker in the image the card was verified in, pinned by its digest. The named volumes keep the downloaded dependencies and the build cache between runs, so the test runs need no network.

docker run --rm --init \
  -v "$PWD":/card -w /card \
  -v fix-go-gomod:/go/pkg/mod \
  -v fix-go-gocache:/root/.cache/go-build \
  golang:1.27.2-trixie@sha256:e58d6f83b3416618d8bcac2b3dde1b7f7e3c4a77d25e88637f8bbae81536c48d \
  sh -c 'go mod download && go build ./... tool'

# Expected: every test passes
docker run --rm --init --network=none \
  -v "$PWD":/card -w /card \
  -v fix-go-gomod:/go/pkg/mod \
  -v fix-go-gocache:/root/.cache/go-build \
  -e IMPL=fixed \
  golang:1.27.2-trixie@sha256:e58d6f83b3416618d8bcac2b3dde1b7f7e3c4a77d25e88637f8bbae81536c48d \
  sh -c 'go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...'

# Expected: an exploit test fails
docker run --rm --init --network=none \
  -v "$PWD":/card -w /card \
  -v fix-go-gomod:/go/pkg/mod \
  -v fix-go-gocache:/root/.cache/go-build \
  -e IMPL=vulnerable \
  golang:1.27.2-trixie@sha256:e58d6f83b3416618d8bcac2b3dde1b7f7e3c4a77d25e88637f8bbae81536c48d \
  sh -c 'go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...'

# Expected: a test fails
docker run --rm --init --network=none \
  -v "$PWD":/card -w /card \
  -v fix-go-gomod:/go/pkg/mod \
  -v fix-go-gocache:/root/.cache/go-build \
  -e IMPL=wrong \
  golang:1.27.2-trixie@sha256:e58d6f83b3416618d8bcac2b3dde1b7f7e3c4a77d25e88637f8bbae81536c48d \
  sh -c 'go tool gotestsum --junitfile reports/junit.xml -- -count=1 ./...'

Each run writes a JUnit report to reports/junit.xml. From the top folder of the download, node run-all.mjs tls-certificate-validation/go-nethttp runs all three modes and checks the expected results, in the container, so it needs Docker and Node.js but not the toolchain.

Download the project ZIP, 24 KB

Verified

Machine

macOS 27.0 (Darwin 27.0.0, arm64); tests in Docker Desktop 4.73.0 (Engine 29.4.3), linux/arm64

Toolchain

• go 1.27.2 (golang:1.27.2-trixie image); also run on 1.26.9 (golang:1.26.9-trixie)
• gotestsum 1.13.0
• semgrep 1.180.0
• gosec 2.29.0
• codeql CLI 2.27.1, codeql/go-queries 1.6.12
• govulncheck 1.8.0

Matrix

fixed: 5 of 5 tests pass; vulnerable: 4 of 5 tests fail (4 exploit tests); wrong: 1 of 5 tests fail (1 exploit test)

Test results

fixed 5/5 pass; vulnerable 4/5 fail (4 exploit tests); wrong 1/5 fail (1 exploit test: the trusted CA's certificate for another host), with --network=none after install; the same on Go 1.26.9

Dependency freshness

No third-party module at run time: the client uses crypto/tls, crypto/x509 and net/http. gotestsum 1.13.0 (2025-09-11) runs the tests; it asks for golang.org/x/text 0.17.0, which GO-2026-5970 affects in a package gotestsum builds, so go.mod raises it to 0.42.0 (2026-09-08). Go 1.27.2 (2026-10-08) is under seven days old but is a security release, with fixes to crypto/tls among others. govulncheck 1.8.0 found no vulnerabilities in the module or the standard library.

Notes

Same scenario, seed (testdata/seed.json, byte for byte the other stacks' file) and test names. The tests mint the PKI with crypto/x509 at start (RSA-2048, as the seed says) and send *.partner.test to a loopback httptest TLS server through the Transport's DialContext, so TLS still sees the partner's name. The wrong implementation is the crypto/tls VerifyConnection example without DNSName (CWE-297), like the Node and Python cards. There is no environment test: Go has no setting that turns verification off, SSL_CERT_FILE and SSL_CERT_DIR change only the system pool, which the fixed client does not use, and crypto/x509 loads that pool once per process, so such a test would depend on test order.

Versions and results hold for the toolchain above. The card's tests are the check: run them with your own versions before relying on the fix.

References

1. Go standard library: crypto/tls Config (InsecureSkipVerify, RootCAs, ServerName, VerifyConnection)
2. Go standard library: crypto/tls example, VerifyConnection
3. Go standard library: crypto/x509 SystemCertPool (SSL_CERT_FILE, SSL_CERT_DIR)
4. Go standard library: crypto/x509 Certificate.VerifyHostname (the Common Name is ignored)
5. Go 1.27 release notes (crypto/x509: SystemCertPool and SSL_CERT_FILE on macOS and Windows)
6. OWASP Transport Layer Security Cheat Sheet
7. RFC 9525: Service Identity in TLS
8. CWE-297: Improper Validation of Certificate with Host Mismatch
9. gosec 2.29.0 rules (G402, G123)

Attack patterns:

• CAPEC-94 at MITRE
• CAPEC-459 at MITRE
• CAPEC-475 at MITRE