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

New Issue

2025-11-02T04:38:31-06:00

GiteaMirror commented

2025-11-02 04:38:31 -06:00

Originally created by @gregkare on GitHub (Nov 6, 2018).

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 (https://github.com/go-gitea/gitea/blob/3d84f1f46b374338710f7da3e8473eb4c97dc63b/cmd/web.go#L83) 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/

Originally created by @gregkare on GitHub (Nov 6, 2018). - 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 - [X] 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 (https://github.com/go-gitea/gitea/blob/3d84f1f46b374338710f7da3e8473eb4c97dc63b/cmd/web.go#L83) `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: ```ini ... [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/

GiteaMirror added the type/bug label 2025-11-02 04:38:31 -06:00

GiteaMirror closed this issue

2025-11-02 04:38:31 -06:00

GiteaMirror commented

2025-11-02 04:38:32 -06:00

@fser commented on GitHub (Nov 28, 2018):

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

@fser commented on GitHub (Nov 28, 2018): 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

GiteaMirror commented

2025-11-02 04:38:32 -06:00

@lafriks commented on GitHub (Nov 28, 2018):

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

@lafriks commented on GitHub (Nov 28, 2018): @fser that is ok as letsencrypt handler will also act as http redirector to redirect http to https

GiteaMirror commented

2025-11-02 04:38:32 -06:00

@fser commented on GitHub (Nov 28, 2018):

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.

@fser commented on GitHub (Nov 28, 2018): 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.

GiteaMirror commented

2025-11-02 04:38:33 -06:00

@lafriks commented on GitHub (Nov 29, 2018):

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 commented on GitHub (Nov 29, 2018): 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

GiteaMirror commented

2025-11-02 04:38:33 -06:00

@lafriks commented on GitHub (Nov 29, 2018):

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

@lafriks commented on GitHub (Nov 29, 2018): It could be also bug can't tell atm as I have not tried this functionality yet :)

GiteaMirror commented

2025-11-02 04:38:33 -06:00

@gregkare commented on GitHub (Dec 5, 2018):

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?

@gregkare commented on GitHub (Dec 5, 2018): 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?

GiteaMirror commented

2025-11-02 04:38:33 -06:00

@gbl08ma commented on GitHub (Dec 9, 2018):

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.

@gbl08ma commented on GitHub (Dec 9, 2018): 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](https://github.com/go-gitea/gitea/blob/b82c14b3d2259912b47fa292b85772ba1d2493d0/cmd/web.go#L83), 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](https://github.com/go-gitea/gitea/blob/b82c14b3d2259912b47fa292b85772ba1d2493d0/cmd/web.go#L155) 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.

GiteaMirror commented

2025-11-02 04:38:34 -06:00

@gregkare commented on GitHub (Dec 11, 2018):

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

@gregkare commented on GitHub (Dec 11, 2018): I have posted a PR here: #5525 (replaced PR, pushed to the wrong org)

GiteaMirror commented

2025-11-02 04:38:34 -06:00

@gregkare commented on GitHub (Dec 12, 2018):

I could confirm that the Let's Encrypt setup in Gitea works now, I deployed the latest Docker tag and now have a valid Let's Encrypt certificate

@gregkare commented on GitHub (Dec 12, 2018): I could confirm that the Let's Encrypt setup in Gitea works now, I deployed the latest Docker tag and now have a valid Let's Encrypt certificate

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2495