Go HTTPS Client: Skip TLS Verify (InsecureSkipVerify) and Safer Options

Use tls.Config InsecureSkipVerify on a dedicated net/http Transport for golang http client skip tls verify only in dev; prefer fixing golang ssl certificate trust with RootCAs instead of golang disable ssl verification in production.

Published

Updated

Read time 4 min read

Reviewed byDeepak Prasad

Go HTTPS Client: Skip TLS Verify (InsecureSkipVerify) and Safer Options

Searches such as golang http client ignore certificate, golang http client skip tls verify, golang http ignore certificate, golang disable ssl verification, and golang insecureskipverify (or insecureskipverify golang) all point at the same knob: crypto/tls.Config.InsecureSkipVerify. A normal golang https request uses the default http.Client, which verifies the server’s golang ssl certificate chain. This page shows how verification fails against badssl.com-style servers, how to configure a client for local debugging only, and what to do instead for real systems.

Tested with Go 1.24 on Linux. Examples call public HTTPS endpoints; run them on your machine with network access.

WARNING
InsecureSkipVerify: true disables TLS authentication. It is appropriate only for short-lived local tests. Do not use it in production: anyone on the network path can impersonate the server (MITM).

Why a golang ssl certificate check fails

Typical x509 errors when you http.Get an HTTPS URL include:

  • Certificate expired or not yet valid.
  • Self-signed or signed by a CA your client does not trust (unknown authority).
  • Hostname mismatch (certificate not valid for the requested DNS name).
  • Missing intermediate certificates on the server.

Sites like badssl.com expose those cases on purpose. Without fixing trust, a golang https request stops with a TLS error before you read the body.

For context on TLS in Go servers, see HTTP and HTTPS in Go. For renewing CAs in the OpenSSL world (different from client InsecureSkipVerify), see renewing root CA material.


golang http client skip tls verify: dedicated http.Client

The usual pattern for golang http ignore certificate in a throwaway test is:

  1. http.DefaultTransport.(*http.Transport).Clone() (Go 1.13+) so you do not mutate the process-wide default transport.
  2. Set TLSClientConfig: &tls.Config{InsecureSkipVerify: true} on that clone.
  3. Build &http.Client{Transport: tr} and use that client only where you accept the risk.
go
package main

import (
	"crypto/tls"
	"io"
	"log"
	"net/http"
)

func main() {
	tr := http.DefaultTransport.(*http.Transport).Clone()
	tr.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

	client := &http.Client{Transport: tr}
	res, err := client.Get("https://self-signed.badssl.com/")
	if err != nil {
		log.Fatal(err)
	}
	defer res.Body.Close()

	if _, err := io.Copy(io.Discard, res.Body); err != nil {
		log.Fatal(err)
	}
	log.Println("status", res.StatusCode)
}

Run it locally: you should get HTTP 200 and a logged status (the page body is HTML from badssl).

Avoid assigning directly to http.DefaultTransport in libraries or long-running programs: it affects every default-client request in the process and is easy to leave on by accident.


Safer alternative: trust your own CA (no InsecureSkipVerify)

For internal services with a company CA or a self-signed cert you control, add the PEM to a x509.CertPool and set RootCAs on tls.Config. Verification stays on; only your trust anchor changes.

go
package main

import (
	"crypto/tls"
	"crypto/x509"
	"log"
	"net/http"
	"os"
)

func main() {
	pool := x509.NewCertPool()
	pem, err := os.ReadFile("corp-ca.pem")
	if err != nil {
		log.Fatal(err)
	}
	if !pool.AppendCertsFromPEM(pem) {
		log.Fatal("no certs parsed")
	}

	tr := http.DefaultTransport.(*http.Transport).Clone()
	tr.TLSClientConfig = &tls.Config{RootCAs: pool}

	client := &http.Client{Transport: tr}
	res, err := client.Get("https://internal.example/")
	if err != nil {
		log.Fatal(err)
	}
	defer res.Body.Close()
	log.Println(res.StatusCode)
}

Replace the URL and PEM path with your real assets.


What happens without skip verify (badssl examples)

Calling the default client against expired or self-signed badssl hosts typically fails with x509: certificate has expired or is not yet valid or certificate signed by unknown authority. That is the behavior you want in production; fixing trust or server configuration is the correct remedy.


Summary

Golang http client ignore certificate behavior comes from tls.Config{InsecureSkipVerify: true} on an http.Transport, wired into an http.Client; keywords like golang http client skip tls verify, golang disable ssl verification, and golang insecureskipverify describe that path. Use Transport.Clone(), io.ReadAll or io.Copy with defer res.Body.Close(), and never treat skip-verify as a product feature. go install ignore certificate is unrelated: use go help environment variables such as GOPROXY, GOSUMDB, and GOINSECURE for module downloads. Clearer copy can help long-tail TLS queries when you already earn impressions, but traffic is not guaranteed to jump from a single refresh.


References


Frequently Asked Questions

1. How do I golang http client ignore certificate errors?

Set TLSClientConfig on an http.Transport to a tls.Config with InsecureSkipVerify true, then use an http.Client with that transport. Prefer cloning the default transport instead of mutating http.DefaultTransport globally, and never ship InsecureSkipVerify to production unless you fully accept MITM risk.

2. What does InsecureSkipVerify do in Go?

It disables server certificate chain and hostname verification for TLS connections using that config. The name is literal: it is insecure. It answers searches like golang insecureskipverify or insecureskipverify golang.

3. Is go install ignore certificate the same as http InsecureSkipVerify?

No. go install uses module proxy and VCS settings (for example GOPROXY, GOSUMDB, GOINSECURE, git HTTPS config). Skipping TLS for the Go HTTP client only affects programs you write with net/http; it does not change the go command’s downloads.

4. How should I trust a self-signed or private CA certificate instead?

Load the PEM with x509.AppendCertsFromPEM into a x509.CertPool, set tls.Config RootCAs to that pool, and keep InsecureSkipVerify false so hostname and chain are still checked against your CA.

5. Can I test with badssl.com from Go?

badssl.com hosts many intentionally broken TLS endpoints (expired, wrong host, self-signed). They are useful for local experiments; your code still needs network access and badssl must be reachable from where you run the binary.
Tuan Nguyen

Data Scientist

Proficient in Golang, Python, Java, MongoDB, Selenium, Spring Boot, Kubernetes, Scrapy, API development, Docker, Data Scraping, PrimeFaces, Linux, Data Structures, and Data Mining. With expertise …