Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/crypto/acme/autocert: seems broken #44894

Closed
zxdev opened this issue Mar 9, 2021 · 6 comments
Closed

x/crypto/acme/autocert: seems broken #44894

zxdev opened this issue Mar 9, 2021 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@zxdev
Copy link

zxdev commented Mar 9, 2021 •
edited by seankhliao 

go version go1.16 darwin/amd64

Does this issue reproduce with the latest release?

Yes, all releases and across various OS

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

fails on CentOS 7, 8, 8 stream, Debian, Arch on a cloud server, so intel

What did you do?

opened port 80/443 and even turned the firewall off for good measure as well

tried this same build using go 15, 15.8, and 16 and on CentOS7, 8, 8 Stream, Arch, Ubunto images

GOOS=linux go build https-test.go
then scp https-test file to remote server, log in and:

ENV={some fqdn here} ./https

func main() {

	fqdn := os.Getenv("HOST")
	if len(fqdn) == 0 {
		log.Println("HOST={fqdn} not set!")
		return
	}

	router := chi.NewMux()
	public(router)

	certManager := autocert.Manager{
		Prompt:     autocert.AcceptTOS,
		HostPolicy: autocert.HostWhitelist(fqdn),   
		Cache:      autocert.DirCache("/var/certs"), 
	}

	srv := &http.Server{
		Addr:         ":https",
		WriteTimeout: time.Second * 15,
		ReadTimeout:  time.Second * 15,
		IdleTimeout:  time.Second * 15,
		Handler:      router,
		TLSConfig: &tls.Config{
			GetCertificate: certManager.GetCertificate,
		},
	}
	log.Printf("https: %s", fqdn)

	go http.ListenAndServe(":http", router)
	srv.ListenAndServeTLS("", "")

}

func public(r *chi.Mux) {

	r.Get("/", func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusTeapot) // 418
	})

	r.Get("/hb", func(w http.ResponseWriter, req *http.Request) {
		w.WriteHeader(http.StatusOK) // 200
		w.Write([]byte("alive"))
	})

	r.Get("/x/endpoint", func(w http.ResponseWriter, req *http.Request) {
		chi.Walk(r, func(method string, route string, handler http.Handler, middlewares ...func(http.Handler) http.Handler) error {
			route = strings.Replace(route, "/*/", "/", -1)
			fmt.Fprintf(w, "%s %s\n", method, route)
			return nil
		})
	})

}

What did you expect to see?

I expect to be able to connect the the server via HTTPS and not get errors.

What did you see instead?

Note: obviously I do not own example.com, stick in whatever you own, I replaced the results with that and replaced my ip with x.x.x.x.
I have used six different domains and tried to get certs for new one.
Port 80/443 are both open on the server.

curl -X GET https://example.com/x/endpoint
curl: (35) error:14004438:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert internal error

2021/03/09 20:40:22 http: TLS handshake error from x.x.x.x:57856: acme/autocert: unable to satisfy "https://acme-v02.api.letsencrypt.org/acme/authz-v3/11437819518" for domain "example.com": no viable challenge type found

This ACME show update 18 days ago, was/is that the source problem?
@gopherbot gopherbot added this to the Unreleased milestone Mar 9, 2021
@seankhliao seankhliao changed the title x/crypto acme seems broken x/crypto/acme/autocert: seems broken Mar 9, 2021
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 9, 2021
@seankhliao
Copy link
Member

CC @bradfitz @x1ddos via owners.

@x1ddos
Copy link

x1ddos commented Mar 9, 2021

Please replace me with someone else in the owners. I have long moved on to other projects. Sorry.

@zxdev
Copy link
Author

zxdev commented Mar 10, 2021 •
edited

I rolled back to a previous codebase that I had used without issue previously and pulled/used the old packages in the module since those servers were and are running just fine.

golang.org/x/crypto v0.0.0-20190618222545-ea8f1a30c443
golang.org/x/net v0.0.0-20200202094626-16171245cfb2

Now I get this error, so it obviously is something that has changed on the letsencrypt side and the library does not correctly support v2 and provides no challenges or something like that.

2021/03/10 04:00:45 http: TLS handshake error from x.x.x.x:55718: 403 urn:acme:error:unauthorized: Error creating new authz :: Validations for new domains are disabled in the V1 API (https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430)

@zxdev
Copy link
Author

zxdev commented Mar 10, 2021 •
edited

From LetsEncrypt:

ACME v1 (Deprecated)
ACME v2 (RFC 8555)

https://letsencrypt.org/docs/acme-protocol-updates/

Perhaps this helps the authors and maintainers. So if you have an old cert, it will still work and renew as long as do you not need a new label OR you have a wildcard cert. If you need a new cart for a new domain, then this is broken. The only simple work around is using certbot, or similar, which of course means you have to let it bind to port 80, so if you are using 80, then you have to take your server down if your program redirects 80 or mirrors 80, which is of course what I do. Or you have to do a dns challenge, which I can't easily do.

This library was marvelous, reverting back to certbot feels so clunky.

@zxdev
Copy link
Author

zxdev commented Mar 12, 2021

resolved:
wasn't passing certManager.HTTPHandler(router) for the 80 connection.
Egg on face.

@zxdev zxdev closed this as completed Mar 12, 2021
@pwaller
Copy link
Contributor

pwaller commented Mar 11, 2022

Sorry if this is OT, but leaving breadcrumb for others: HTTP should be unnecessary. In my case I got no viable challenge type found because I did not have a firewall rule allowing letsencrypt to reach port 443 on my server so it could use the tls-alpn-01 challenge. I was able to reach 443, but not everyone else. I'd created the firewall rule to allow all access to 443, but neglected to attach it to the instance.

@golang golang locked and limited conversation to collaborators Mar 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@x1ddos @pwaller @gopherbot @seankhliao @zxdev