If you're doing to do something custom and wire up a weird contraption, the https://godoc.org/golang.org/x/crypto/acme package has HTTP-01 support already. Have you got that working first?

autocert is supposed to be magic for a common config. Maybe your use case will also become a common config, but it's not clear it is already.

FWIW, I also run a bunch of autocert sites on GKE, but it's just using Google's TCP proxy, so I still do the SNI+HTTPS, without HTTP proxies or TLS in front of me. You can implement the autocert cache interface and put the certs on GCS or something.

In any case, what API do you have in mind? I'd say make it work first and then propose the least invasive API change possible.

The API change I had in mind is adding this exported field to autocert.Manager:

// ServeMux optionally specifies a request multiplexer to use for HTTP-01 challenges.
// If specified, HTTP-01 challenges will be preferred over TLS-SNI challenges.
ServeMux *http.ServeMux

Usage would then look something like:

func main() {
    m := autocert.Manager{
        Prompt:     autocert.AcceptTOS,
        HostPolicy: autocert.HostWhitelist("example.org"),
        Cache:      autocert.DirCache("/mnt/autocert/cache"),
        ServeMux:   http.DefaultServeMux, // Used to serve HTTP-01 challenge responses.
    }
    go func() {
        t := time.NewTicker(time.Minute)
        for range t.C {
            if cert, err := m.GetCertificate(&tls.ClientHelloInfo{ServerName: "example.org"}); err != nil {
                // Log error.
            } else {
                // Store cert in place used by TLS-terminating proxy.
            }
        }
    }()
    http.ListenAndServe(":http", nil)
}

This could be done just using the acme package, but I'd like to take advantage of the conveniences autocert provides.

In any case, I'll try and get it working first then report back. Thanks for the feedback!

The concrete type http.ServeMux should never appear in API surface. It's a silly little helper type; the fundamental type is http.Handler.

And instead of naming the field ServeMux, you'd write what it's used for. Actually, try writing the docs. What would you say?

type Manager struct {
     // Foo optionally specifies a Handler to ...
     // If nil, ...
     Foo http.Handler

Also, that one minute polling loop is kinda gross. Any polling is gross: it's either too fast or too slow. You want to have no TLS for a minute while you wait to install the cert?

Any API needs to work instantly and not involve loops with sleeps.

Wouldn't it be even simpler to just have Manager implement http.Handler? Then one could do:

m := &autocert.Manager{Prompt: autocert.AcceptTOS}
http.Handle("/.well-known/acme-challenge/", m)
http.ListenAndServe(":80", nil)

Manager would still need to know which challenge type is preferred, tls-sni or http-01, but this feels less intrusive towards existing API.

That seems like too big of a cut through the abstractions. I'd rather not add a ServeHTTP method and make users know or think about the ACME protocol. That sends the wrong message about how Manager is supposed to be used.

RE: Polling - yes, it's ugly, the client could just poll once every RenewBefore or so, but it would be nicer if Manager exposed a way of watching for updates to certificates. Something like:
func (m *Manager) WatchCertificate(hello *tls.ClientHelloInfo) <-chan *tls.Certificate
But this would be a fairly invasive change to Manager.

RE: ServeMux/Handler. I don't understand how one can add a Handler for a path (e.g./.well-known/ to a Server by passing Manager an http.Handler. I think it would have to be the other way around, having Manager implement http.Handler like Alex suggests, or perhaps adding a function to Manager's interface like:
func (m *Manager) HTTP01ChallengeHandler() http.Handler

Given this would expose details of the ACME protocol to users of autocert.Manager, and that's not desirable, I think I'll just use the acme package directly as suggested by Brad in the first reply. Thanks all!