How do you serve HTTPS from a Go net/http server, and where does a tls.Config go?

## The two ways to start an HTTPS listener Go's `net/http` gives you a package-level convenience function and a method on `http.Server`, and the difference between them is the whole point of this question. ```go // convenience: no place to configure TLS http.ListenAndServeTLS(":8443", "cert.pem", "key.pem", mux) ``` That call creates an `http.Server` internally, and you never get a reference to it. It is fine for a demo. It is not fine for a service that has to state a minimum protocol version, because the only place TLS options live is the server's `TLSConfig` field. ```go srv := &http.Server{ Addr: ":8443", Handler: mux, TLSConfig: &tls.Config{ MinVersion: tls.VersionTLS12, }, } log.Fatal(srv.ListenAndServeTLS("cert.pem", "key.pem")) ``` `TLSConfig` is a `*tls.Config` from `crypto/tls`. Everything TLS-related on the serving side is a field on that struct — the version floor, the cipher-suite list for older protocol versions, the certificates, the callbacks. `http.Server` itself has no TLS fields beyond that one pointer. ## What the two files are `certFile` is a PEM file containing the server's certificate. If the certificate was issued by an intermediate CA rather than directly by a root, the intermediates must be concatenated into the same file, leaf first, in issuing order. Go's own TLS client does not go and fetch missing intermediates, and neither do many other clients, so a chain that verifies in your browser can still fail from a Go program if you shipped only the leaf. `keyFile` is the PEM private key that matches the leaf certificate. If the key is in the same file as the certificate, you may pass the same path for both arguments. ## Loading the certificate yourself Sometimes the files are not files: the certificate comes from a secret store, or you need one certificate per hostname. Then you fill the config instead: ```go cert, err := tls.LoadX509KeyPair("cert.pem", "key.pem") if err != nil { return err } srv.TLSConfig = &tls.Config{ MinVersion: tls.VersionTLS12, Certificates: []tls.Certificate{cert}, } return srv.ListenAndServeTLS("", "") ``` Empty filenames are legal precisely when the config can already produce a certificate — `Certificates` is non-empty, or `GetCertificate` is set. `GetCertificate` is a callback that receives the client's hello and returns the certificate to present, which is how one listener serves several hostnames. ## Serving over a listener you own `ListenAndServeTLS` creates the TCP listener for you from `srv.Addr`. When you need the listener first — to bind port 0 and discover the port, to serve on a Unix socket, to hand the listener in from a supervisor — use `srv.ServeTLS(l, certFile, keyFile)` with an already-created `net.Listener`. The certificate arguments behave identically. ## Details worth knowing early `net/http` does not use your `*tls.Config` object directly: when the server starts it takes a clone and adds the ALPN protocol names it supports to `NextProtos`, which is how HTTP/2 gets negotiated. Two consequences follow. First, mutating `srv.TLSConfig` after the server has started changes nothing for that listener — set it before you start. Second, if you set `NextProtos` yourself, you are overriding what the server would have advertised, so you can accidentally turn HTTP/2 off. A `*tls.Config` is meant to be shared and read concurrently by every connection. Treat it as immutable once the server is running; if you need a variant, use its `Clone` method rather than editing the live one. Finally, an HTTPS server is an ordinary `http.Server` — the same handlers, the same mux, the same everything. Serving HTTPS is a matter of which start method you call and what you put in one struct field, not of a different server type. Inside a handler, `r.TLS` is a `*tls.ConnectionState` (nil for a plaintext request), which is how a handler learns what was negotiated for the request it is serving.