Server only listening to HTTP_PORT with TLS when Let's Encrypt is enabled

[gregkare]

• Gitea version (or commit ref): 1.6.0-rc2
• Operating system: Linux / macOS
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

Let's Encrypt support was merged in #4189 and ships in 1.6.0-rc1. Has anyone been able to make this work? Reading the code (

gitea/cmd/web.go

Line 83 in 3d84f1f

go http.ListenAndServe(listenAddr+":"+setting.PortToRedirect, certManager.HTTPHandler(http.HandlerFunc(runLetsEncryptFallbackHandler))) // all traffic coming into HTTP will be redirect to HTTPS automatically (LE HTTP-01 validatio happens here)

) PORT_TO_REDIRECT from the config file is supposed to be used to redirect HTTP to HTTPS and also by Let's Encrypt to generate certificates. However I'm only getting a daemon running on the HTTP_PORT (using TLS). When ENABLE_LETSENCRYPT is set to false and REDIRECT_OTHER_PORT is set to true a daemon listens on PORT_TO_REDIRECT and redirects HTTP to HTTPS. I can reproduce the issue running the 1.6.0-rc2 binary directly on macOS, as well as in Kubernetes/Docker.

Update: Setting PORT_TO_REDIRECT or not leads to the same result, only listening on HTTPS

Here are the relevant parts of my config:

...
[server]
PROTOCOL = https
HTTP_PORT = 3000
DOMAIN = gitea.example.com
PORT_TO_REDIRECT = 3001
ENABLE_LETSENCRYPT = true
LETSENCRYPT_ACCEPTTOS = true
LETSENCRYPT_DIRECTORY = https
LETSENCRYPT_EMAIL = ops@example.com

Am I missing something? I have checked the code, as well as read https://docs.gitea.io/en-us/https-setup/

[fser]

Same here! Although I noticed something in the code:

	case setting.HTTPS:
		if setting.EnableLetsEncrypt {
			err = runLetsEncrypt(listenAddr, setting.Domain, setting.LetsEncryptDirectory, setting.LetsEncryptEmail, context2.ClearHandler(m))
			break
		}
		if setting.RedirectOtherPort {
			go runHTTPRedirector()
                }

My point being, if LetsEncrypt is enabled, then the RedirectOtherPort will not be reached. I was tempted to swap the two conditions...

Ref: https://github.com/go-gitea/gitea/blob/master/cmd/web.go#L174-L181

[lafriks]

@fser that is ok as letsencrypt handler will also act as http redirector to redirect http to https

[fser]

How does it work? It's only listening on HTTP_PORT, with or without REDIRECT_OTHER_PORT set to true and PORT_TO_REDIRECT to 8080.

[lafriks]

It does not use REDIRECT_OTHER_PORT but does use PORT_TO_REDIRECT here:
https://github.com/go-gitea/gitea/blob/master/cmd/web.go#L83

[lafriks]

It could be also bug can't tell atm as I have not tried this functionality yet :)

[gregkare]

I do not see anything listening on PORT_TO_REDIRECT either, with ENABLE_LETSENCRYPT set to true. Has someone managed to make that feature work?

[gbl08ma]

I have the same issue: when ENABLE_LETSENCRYPT is set to true, Gitea does not listen on PORT_TO_REDIRECT as documented.

I took a couple of minutes to look at the code and I identified the problem:

On line 83 of cmd/web.go, the HTTP server is supposed to be started. This goroutine is launched and its error return value is ignored, which means there are no errors in any logs (if there were, people would have certainly already caught the bug).

The problem lies in this expression: listenAddr+":"+setting.PortToRedirect. If you trace where listenAddr is actually set, you'll see that on line 155 the port will already have been appended. So on line 83, it is actually attempting to listen on an address like 0.0.0.0:443:80, which I imagine actually results in an error, but of course, the error return value is ignored due to the way the goroutine is launched.

If in that expression on line 83 listenAddr is replaced with setting.HTTPAddr, the bug should be fixed. I could open a pull request but I already spent three hours today trying to set up Gitea for the first time, scratching my head at what could go wrong and messing with the configuration because "certainly this must have been tested, it's documented right there, it must be a problem with my config", then convincing myself there must be a problem in the code, which there was. Ugh.

[gregkare]

I have posted a PR here: #5525 (replaced PR, pushed to the wrong org)