Middle · Go service security

The certificate error is hidden with InsecureSkipVerify

A development HTTPS request fails verification. A patch sets InsecureSkipVerify and now the request succeeds. What evidence is lost?

Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.

EXAMPLE · FRAGMENT UNLESS A COMPLETE PROGRAM IS SHOWN

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)
}

Reveal a strong answer

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.
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. 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.
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.

Common trap

Making the error disappear does not establish the correct peer or a safe trust policy.

Try it

Use a scoped test/private trust setup and test wrong hostname, unknown root, expiry and certificate rotation.

Worked solution

Disabling verification removes the intended peer-authentication check; encryption alone can still connect to the wrong endpoint. Fix the deliberate trust relationship and expected hostname rather than accepting arbitrary certificates. Keep development test roots separate from production, plan rotation and distinguish TLS identity from application authorization and payload validation. A successful unverified request is not a secure integration test.

Change the constraint

What additional authorization is needed after a valid mTLS certificate identifies a workload?

How did you do?

Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.

Not marked. Progress stays on this browser, separate from course completion.

Primary references

Checked 2026-10-28. Use documentation for your pinned runtime, driver and tool version.