net/http: something about ACME letsencrypt

[coolaj86]

Solution (Note to Les Googlers)

My question was, as I misinterpreted the documentation.

• GetCertificate == SNICallback
• You cannot cast net.Conn to http.Conn, you can only cast net.Listener to http.Listener
  • i.e. server := &http.Serve{}; server.Server(tlsListener)

See examples at

• https://github.com/coolaj86/golang-https-example/tree/https-server
• https://github.com/coolaj86/golang-https-example

The crux of the issue In 68 lines:

package main

import (
    "crypto/tls"
    "fmt"
    "net"
    "net/http"
    "os"
    "path/filepath"
    "strconv"
    "strings"
)

type myHandler struct{}

func (m *myHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    fmt.Println(r.Host)
    fmt.Println(r.Method)
    fmt.Println(r.RequestURI)
    fmt.Println(r.URL) // also has many keys, such as Query
    for k, v := range r.Header {
        fmt.Println(k, v)
    }
    fmt.Println(r.Body)

    // End the request
    fmt.Fprintf(w, "Hi there, %s %q? Wow!\n\nWith Love,\n\t%s", r.Method, r.URL.Path[1:], r.Host)
}

func main() {
    port := uint(8443)
    certsPath := "/etc/letsencrypt/live"
    defaultHost := "localhost.daplie.com"

    fmt.Printf("Loading Certificates %s/%s/{privkey.pem,fullchain.pem}\n", certsPath, defaultHost)

    privkeyPath := filepath.Join(certsPath, defaultHost, "privkey.pem")
    certPath := filepath.Join(certsPath, defaultHost, "fullchain.pem")
    cert, err := tls.LoadX509KeyPair(certPath, privkeyPath)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Couldn't load default certificates: %s\n", err)
        os.Exit(1)
    }

    addr := ":" + strconv.Itoa(int(port))

    conn, err := net.Listen("tcp", addr)
    if nil != err {
        fmt.Fprintf(os.Stderr, "Couldn't bind to TCP socket %q: %s\n", addr, err)
        os.Exit(1)
    }

    tlsConfig := new(tls.Config)
    tlsConfig.Certificates = []tls.Certificate{cert}
    tlsConfig.GetCertificate = func(clientHello *tls.ClientHelloInfo) (*tls.Certificate, error) {
        return &cert, nil
    }
    tlsListener := tls.NewListener(conn, tlsConfig)

    server := &http.Server{
        Addr:    addr,
        Handler: &myHandler{},
    }

    host := strings.ToLower(defaultHost)
    fmt.Printf("Listening on https://%s:%d\n", host, port)
    server.Serve(tlsListener)
}

Original Question

https://LetsEncrypt.org's release is just around the corner, but it's currently not possible to dynamically retrieve and renew certificates in go with an active http server.

To do so requires fixing a tiny regression introduced sometime between the move from httputils and now. See https://golang.org/pkg/net/http/httputil/#ServerConn.

We need to re-expose http.NewConn and http.conn.Serve.
See the diff: coolaj86@1a30898

I've got a working demo of dynamically loading certificates with this change here:
https://gist.github.com/coolaj86/16ed8fd810e19dec71be

I've already signed the CLA and with a little coaching I'm sure I could turn my example into an appropriate test case, but I'm way out of my league with the 37-page explanation of how to make a pull request...

See also #11649

[bradfitz]

I'm a big fan of LetsEncrypt, but please describe what you need and not what your proposed fix is. The proposed fix is not acceptable (we won't be exposing internals), but I don't even know what the problem is.

[coolaj86]

Thanks Brad,

Here's a user story:

• Bob sign up with Awesome Host
• He gets a free domain that points to one of Awesome Host's servers
• He uploads some files and they go into a specific path /srv/www/bob.example.com
• Now someone visits bob.example.com.
• The server checks in it's [memory] cache, but there is no certificate
• There server checks a well-known location on disk /etc/letsencrypt/live/bob.example.com, no dice
• The server runs letsencrypt and then downloads the certificates to /etc/letsencrypt/live/bob.example.com

Instead of knowing what all hosts and certificates are beforehand, and without having to restart the server, the service can host secure websites dynamically. That's what I'm doing. It's as easy as pie in node.js because they expose an SNICallback before certificates are handled.

Since go currently requires so much statically defined up-front, the easiest way to accomplish this is to manually create a tlsConn from a net.Conn and then pass that to http.newConn.

Also, it's not exposing "internals" any more than it used to or any more than the TLS and net modules currently do (see my example). It's simply exposing a capability.

I suppose you could also add an SNICallback like node.js does, but from the code I looked at, it seems that that would be far more changes rather than taking the approach that http.ListenAndServe and http.ListenAndServeTLS approach, which would simply encapsulate capability in a composite style.

Another option perhaps would be to move a more complete version of what I've created as https.ListenAndServeSNI, which still needs an SNICallback.

Is that explanation clear?

[bradfitz]

I think you just need to implement your own net.Listener and pass that to a net.Server's Serve. The net.Listener can return any net.Conn with its own *tls.Conn validating things as needed.

[bradfitz]

So you need to present a TLS server certificate as a function of the client's presented SNI hostname?

/cc @agl

[coolaj86]

Yes, that's what I've done. But then I also need to pass it to http.NewConn.

And yes, I need to see the servername in order to know which certificate to pass, I won't know it on startup.

That's all being done in the demo I've been referencing here:
See https://github.com/coolaj86/authentication-as-a-service/blob/master/https/https.go#L64

(the repo is obviously not intended for the story I described, but it may have some similar aspects - and one thing leads to another...)

This is actually my first go project (coming from node.js).

[agl]

Does crypto/tls.Config.GetCertificate not work for you? (Note: the behaviour of that changed a little since Go 1.4.)

[coolaj86]

I don't see what that has to do with the server sending the client a certificate dynamically, but I'm brand new to go.

Here's the rough code without error checking, channels, goroutines, etc:

// I start a raw TCP server
ln, err := net.Listen("tcp", ":" + config.Port)

// I begin accepting connections
conn, err := ln.Accept()

// the vhost pkg peeks at the incoming buffer and let's me see the servername
tlsConn, err := vhost.TLS(conn)

// I grab the SNI
servername := tlsConn.Host()

// Now I want to determine which certificate to issue
// 1. check some cache I create (or maybe GetCertificate?)
// 2. if the expiration is bad, jump ahead to step 5
// 3. if it doesn't exist check on the file system
// 3. if it doesn't exist try SNICallback (from user code)
// 4. if it doesn't exist, try retrieving a brand new certificate from letsencrypt.org
// 5. if that fails, return a dummy certificate

// Now make the encrypted TCP plainly readable
plainConn := tls.Server(tlsConn, tlsConfig)

// Now make it an http server request
srv := &http.Server{Handler: myHandler}
c, err := srv.NewConn(plainConn)

// Now handle that http request
go c.Serve()

When the server starts I may not have the certificate.
I want to delay creating a tls.Config object until I know the servername indication.
Then I want to handle the request as http.

What I'm trying to build is basically

type SNICallback func(domainname string) (t *tls.Config)
http.ListenAndServeSNI(addr string, sniCallback SNICallback, handler Handler) error

Except I want a build a higher-level function that would use such a function with letsencrypt. For the time being I'd just shell out to the letsencrypt python client and there's someone already working on a go client for use with caddyserver (and hopefully the code I'm working on will also find its way there).

[coolaj86]

Sorry, I didn't understand what GetCertificate was when I read through it the first time. I thought that was saying to give me the certificate that was issued to the client.

GetCertificate == SNICallback

Okay, yes, that's the piece that I was missing and didn't discover as I was greping and googling and ctrl+Fing around for "SNI" and "ServerName", and whatnot.

[coolaj86]

Updated: I had ClientCAs confused with RootCAs, now this reads correctly

I got my demo implemented and then I realized that there's not a way to specify the x509.CertPool with tls.Conn.GetCertificate.

I could keep tlsConfig.RootCAs and add to it, but then I have no way to manage it and the docs specify that I must not modify it, so I couldn't replace it.

I could solve this problem manually, but again, there's no way for me to cast net.Conn or tls.Conn to http.Server.Conn, so again, I can't.

Why would I want to manage tlsConfig.RootCAs myself?

Let's say that I'm loading hundreds or thousands of certificates over a long period of time - many of which are transient, occasionally I may want to flush the pool and start over (kilobytes turn to megabytes and so on).

Also, I assume that the x509.CertPool is inspected in such a way that duplicate chains are ignored and not added and that the only the necessary chain is sent to the browser based on the request, but the documentation doesn't explicitly state either for tls.Conn.RootCAs or x509.CertPool.

[coolaj86]

On second thought, maybe that's just me exhibiting typical control-freakishness programmer paranoia.

My app probably won't become that popular and even if I were BlueHost and I loaded every intermediate certificate in the whole world over the next 3 years without restarting the service, there are only maybe a few hundred intermediates in the world and since most of the certificates would be provisioned from the top 10%, it would only be a few dozen that actually get loaded.

What do you think?

Is there value in being able to replace CertPool?

Is there value in being able to create http.Server.Conn from net.Conn?