Around Go: service security · 3 MIN READ

TLS: verify the peer instead of disabling the error

Keep certificate-chain and hostname verification while making trust and rotation explicit.

A TLS connection can encrypt traffic to the wrong peer if verification is disabled. Certificate chain trust and hostname identity both matter; changing a boolean until a development request succeeds can silently remove production authentication. Use a deliberate trust store, keep the expected server identity tied to the configured destination and handle private development certificates through a separate test trust configuration.

security · A MAP OF THE IDEA

Choose expected peer
Configure controlled trust
Verify chain + name
Test rotation and failures

Useful when

Keep certificate-chain and hostname verification while making trust and rotation explicit.
Makes the owner and the failure boundary explicit.

Watch out

Do not solve certificate failures by setting InsecureSkipVerify or by accepting every certificate in a callback.
Run native service and failure tests in your own development environment.

Implementation & operation cost: Additional state and tests must be justified by the demonstrated failure; this lesson is not a requirement for every Go program.

The contract and the failure

Work through the example

Use current platform Go defaults and the deployment’s reviewed minimum TLS policy. Configure private roots through a controlled CA process and test hostname mismatches, expired certificates and rotation. For mTLS, define both certificate verification and application authorization for the resulting identity. Plan long-lived connection behavior during rotation and shutdown.

package main

import (
	"crypto/tls"
	"fmt"
	"net/http"
	"net/http/httptest"
	"time"
)

func main() {
	server := httptest.NewTLSServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { _, _ = w.Write([]byte("ok")) }))
	defer server.Close()
	// This test helper trusts only its own test server certificate.
	client := server.Client()
	client.Timeout = 2 * time.Second
	config := client.Transport.(*http.Transport).TLSClientConfig
	fmt.Println(config.InsecureSkipVerify == false)
	resp, err := client.Get(server.URL)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()
	fmt.Println(resp.StatusCode, resp.TLS.Version >= tls.VersionTLS12)
}

Read the code

The httptest client trusts its associated test certificate without setting InsecureSkipVerify. It demonstrates a scoped native test trust relationship, not a reason to ship that test certificate or trust arbitrary self-signed endpoints. The last check inspects this local test connection’s negotiated TLS version; it does not describe a public endpoint’s configuration.

Production decisions

Do not solve certificate failures by setting InsecureSkipVerify or by accepting every certificate in a callback. TLS does not validate a JSON payload, authorize an object or remove SSRF risk. Keep signing keys and token material out of telemetry. Test a wrong hostname, untrusted root, expired certificate, unavailable revocation/rotation dependencies and the operational recovery path.

Explain it in an interview

A development endpoint has an untrusted certificate. Is disabling verification a production fix? No. Supply the intended test or private trust relationship and verify the expected peer; keep chain and hostname verification in production. Describe the state before the operation, its owner, the failure between steps and the evidence you would test. Distinguish what this example demonstrates from the infrastructure a production service still needs.

TAKE THIS WITH YOU

Keep certificate-chain and hostname verification while making trust and rotation explicit. No. Supply the intended test or private trust relationship and verify the expected peer; keep chain and hostname verification in production.

Check your understanding

A development endpoint has an untrusted certificate. Is disabling verification a production fix?

Go to the source

Progress stays in this browser. No account needed.