tls: server selected unsupported protocol version 301

The number is the version code in hexadecimal without the 0x prefix: 300 = SSL 3.0, 301 = TLS 1.0, 302 = TLS 1.1. HTTP clients prefix "Get \"https://…\": ". A TLS 1.0-only server built on a current library refuses instead of downgrading, and Go then reports "remote error: tls: protocol version not supported" (seen against openssl s_server -tls1).

Go crypto/tls client — the server chose TLS 1.0 (0x0301) or 1.1 (0x0302), below Go's minimum

What it means

The server answered Go's ClientHello by choosing a TLS version Go's client does not allow: 301 is the hexadecimal version code of TLS 1.0, 302 of TLS 1.1. Go clients require TLS 1.2 or newer by default (since Go 1.18), so they abort the handshake. The server needs to support TLS 1.2+.

Why it happens

The server only supports TLS 1.0 or 1.1
common
Old appliances, embedded devices, legacy Windows servers and outdated load balancers.
Go's client minimum is TLS 1.2
common
Since Go 1.18 the default tls.Config.MinVersion for clients is TLS 1.2; programs rebuilt with a newer Go stop talking to TLS 1.0 servers without any code change.

How to fix it

Upgrade the server's TLS

Enable TLS 1.2 (and 1.3) on the server or put a modern TLS terminator in front of it.

text

Upgrade the server (or the appliance firmware / TLS terminator in front of it) to TLS 1.2 or 1.3.
0x0301 = TLS 1.0, 0x0302 = TLS 1.1, 0x0303 = TLS 1.2, 0x0304 = TLS 1.3.

Last resort: a dedicated client with MinVersion TLS 1.0

Lowering MinVersion in a client used only for that legacy device restores connectivity. TLS 1.0 is deprecated (RFC 8996) and lacks modern protections; keep such traffic on trusted networks and never set it on shared transports.

// Last resort for one legacy device on a trusted network: a dedicated client
legacy := &http.Client{Transport: &http.Transport{TLSClientConfig: &tls.Config{
	MinVersion: tls.VersionTLS10, // only for this client; never in a shared transport
}}}
resp, err := legacy.Get("https://legacy.example.com:8443/")