Go

A Complete Guide to Securely Connecting Go Servers and Clients Using Mutual TLS

How to use TLS, client authentication, and CA certificates in Go Servers and Clients

Create a private key and request a certificate for your Go server

Before you can teach your server to speak TLS, you will need a certificate issued by a trusted certificate authority (CA). If your organization already runs its own CA and you have a private key and certificate for your Go server, along with your CA's root certificate, you can skip to the next step.

To request a certificate from your CA using the step CLI, bootstrap your CA with step ca bootstrap and run the following command (sub the server name for the actual name / DNS name of your Go server).

$ step ca certificate "myserver.internal.net" server.crt server.key

Your certificate and private key will be saved in server.crt and server.key respectively.

Request a copy of your CA root certificate, which will be used to make sure each application can trust certificates presented by other applications.

$ step ca root ca.crt

Your certificate will be saved in ca.crt.

Configure Go to authenticate itself with its TLS certificate

We now want to instruct our Go server to identify itself using the certificate issued in the last step and to force clients to connect over TLS.

In your server's Go file, we pass the server's certificate and private key into Go's convenient API to launch a HTTPS listener.

// ...

http.ListenAndServeTLS(":9443", "server.crt", "server.key", nil)

// ...

Configure Go to require clients to authenticate with a certificate issued by your CA

To tell Go to use mutual TLS and not just one-way TLS, we must instruct it to require client authentication to ensure clients present a certificate from our CA when they connect.

In your server's Go file, we pass a TLS stack configuration into the server initalization. The configuration enables strict client certificate verification against all trusted root certificates in the CA pool we create. Finally, we call the server's API to create a HTTPS listener using its own certificate and private key for client-side verification.

// ...

caCert, _ := ioutil.ReadFile("ca.crt")
caCertPool := x509.NewCertPool()
caCertPool.AppendCertsFromPEM(caCert)

tlsConfig := &tls.Config{
    ClientCAs: caCertPool,
    ClientAuth: tls.RequireAndVerifyClientCert,
}
tlsConfig.BuildNameToCertificate()

server := &http.Server{
    Addr:      ":9443",
    TLSConfig: tlsConfig,
}

server.ListenAndServeTLS("server.crt", "server.key")

// ...

That's it! Go should now be able to receive TLS connections from clients who authenticate themselves using a certificate issued by your trusted CA.

Create a private key and request a certificate for your Go client

Request a new certificate from your CA to represent your Go client.

$ step ca certificate "myuser" client.crt client.key

Your certificate and private key will be saved in client.crt and client.key respectively.

Make a request from Go using mutual TLS

Now, we need only to configure our Go client to make authenticated requests using our certificate and private key. The CA root certificate will be used to verify that the client can trust the certificate presented by the server.

In your Go code, we specify a TLS stack configuration for your client(s) making requests. The configuration includes 1.) root certificates of all trusted CAs for verification of the server's certificate in a pool we create. And 2.) the client's own certificate and private key for server-side client certificate verification.

// ...

caCert, _ := ioutil.ReadFile("ca.crt")
caCertPool := x509.NewCertPool()
caCertPool.AppendCertsFromPEM(caCert)

cert, _ := tls.LoadX509KeyPair("client.crt", "client.key")

client := &http.Client{
    Transport: &http.Transport{
        TLSClientConfig: &tls.Config{
            RootCAs: caCertPool,
            Certificates: []tls.Certificate{cert},
        },
    },
}

// Make a request
r, err := client.Get("https://myserver.internal.net:9443")

// ...

Automate certificate renewal

By default, step-ca issues certificates with a 24 hour expiration. Short-lived certificates have many benefits but also require that you renew your certificates each day before they expire. How you renew certificates is often dependent on how you deploy your application. See the step-ca certificate lifecycle management docs for more information.

All documentation content from the Hello mTLS project is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

Creative Commons License