Perhaps the autocert package should special case localhost and just serve a self-signed cert in that case. That'd be useful for testing and consistency.
I filed https://github.com/golang/go/issues/20640 to think about that. On Tue, Jun 6, 2017 at 10:22 AM, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > tl;dr: You need a) a publicly routed IP address (either IPv4 or IPv6 is > fine), b) a publicly resolvable domain that points to that IP address and > c) actually point your client (browser) to that domain. > > Long explanation: > > The HTTP client will use SNI to tell the server the domain it needs a cert > for. The autocert package will then check that against the provided > HostPolicy (in the case of NewListener, that means "is it one of the listed > domains") and tell LetsEncrypt that it wants a certificate for that domain. > LetsEncrypt will then verify, that you actually own that domain and the > corresponding key (thus the need for a publicly resolvable Domain. > LetsEncrypt can't verify that you are "localhost"). There are multiple > challenges for that (I believe there is one that uses DNS and one that uses > SNI?), autocert implements only one the latter (I think) and tells > LetsEncrypt which. As it doesn't implement the DNS based challenge, > LetsEncrypt needs to resolve the domain to an IP and make a connection to > it (thus the need for a publicly routed IP address) to verify, that there > actually is someone with the correct key sitting behind it. That'll be > autocert. Finally, if all that works, LetsEncrypt issues a certificate for > that domain and gives it to your server; again, the autocert package > handles the receiving and caching of that cert. Once it has the cert, it > will finish the TLS handshake with the HTTP client and you have a valid > connection. Future connections will just reuse the cached certificate, > given that the client sends the same domain via SNI. > > Hope that helps. It's quite a bit of complexity behind that one line of > code; but if you actually fulfill above requirements a, b and c, it will be > a total breeze to get good, strong certificates for however many domains > you need :) > > On Tue, Jun 6, 2017 at 7:07 PM, Sankar <sankar.curios...@gmail.com> wrote: > >> Hi >> >> I saw the tweet https://twitter.com/mholt6/status/848704744474292224 and >> decided to try out the code >> >> log.Fatal(http.Serve(autocert.NewListener("mydomain.com >> <http://example.com/>"), handler)) >> >> but when I try to visit: https://localhost:443, I get an error on the >> server console as: server name component count invalid >> >> Is there any detailed documentation on how to get letsencrypt working >> with golang ? >> >> I am using go 1.8.3 >> >> Google gave me https://github.com/golang/go/issues/17053 , but I am not >> able to understand if the letsencrypt support is fully landed or not. Can >> anyone point me to docs and best practices for testing at localhost and >> deploying at production, with https and letsencrypt ? Thanks. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
