Set up let's encrypt

I am glad that I found gitea and set it up successfully so far. However I strougle with setting up the let’s encrypt certificates.

When I start up the server I get this logs:

023/02/16 20:39:31 cmd/web.go:220:listen() [I] [63ee8673-2] Listen: https://0.0.0.0:3000
2023/02/16 20:39:31 cmd/web.go:224:listen() [I] [63ee8673-2] AppURL(ROOT_URL): http://git.stubenhocker.tech/
2023/02/16 20:39:31 cmd/web.go:227:listen() [I] [63ee8673-2] LFS server enabled
1.6765763711210723e+09  info    maintenance     started background certificate maintenance      {"cache": "0xc0007ea000"}
1.6765763711233811e+09  info    obtain  acquiring lock  {"identifier": "git.stubenhocker.tech"}
1.676576371132452e+09   info    obtain  lock acquired   {"identifier": "git.stubenhocker.tech"}
1.6765763711332061e+09  info    obtain  obtaining certificate   {"identifier": "git.stubenhocker.tech"}
1.6765763711387722e+09  info    waiting on internal rate limiter        {"identifiers": ["git.stubenhocker.tech"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": "alpha@anonymous.digital"}
1.6765763711394014e+09  info    done waiting on internal rate limiter   {"identifiers": ["git.stubenhocker.tech"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": "alpha@anonymous.digital"}
1.676576372261081e+09   info    acme_client     trying to solve challenge       {"identifier": "git.stubenhocker.tech", "challenge_type": "tls-alpn-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
1.676576373662748e+09   error   acme_client     challenge failed        {"identifier": "git.stubenhocker.tech", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "82.197.161.171: Connection refused", "instance": "", "subproblems": []}}
1.67657637366336e+09    error   acme_client     validating authorization        {"identifier": "git.stubenhocker.tech", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "82.197.161.171: Connection refused", "instance": "", "subproblems": []}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/968237346/165176688256", "attempt": 1, "max_attempts": 3}
1.6765763750080686e+09  info    acme_client     trying to solve challenge       {"identifier": "git.stubenhocker.tech", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
1.6765763760269008e+09  error   acme_client     challenge failed        {"identifier": "git.stubenhocker.tech", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "82.197.161.171: Fetching http://git.stubenhocker.tech/.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU: Connection refused", "instance": "", "subproblems": []}}
1.6765763760271325e+09  error   acme_client     validating authorization        {"identifier": "git.stubenhocker.tech", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "82.197.161.171: Fetching http://git.stubenhocker.tech/.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU: Connection refused", "instance": "", "subproblems": []}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/968237346/165176692386", "attempt": 2, "max_attempts": 3}
1.6765763760274005e+09  error   obtain  could not get certificate from issuer   {"identifier": "git.stubenhocker.tech", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 400 urn:ietf:params:acme:error:connection - 82.197.161.171: Fetching http://git.stubenhocker.tech/.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU: Connection refused"}
1.6765763760275662e+09  info    obtain  releasing lock  {"identifier": "git.stubenhocker.tech"}
2023/02/16 20:39:36 cmd/web.go:269:listen() [C] [63ee8673-2] Failed to start server: git.stubenhocker.tech: obtaining certificate: [git.stubenhocker.tech] Obtain: [git.stubenhocker.tech] solving challenge: git.stubenhocker.tech: [git.stubenhocker.tech] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 82.197.161.171: Fetching http://git.stubenhocker.tech/.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU: Connection refused (ca=https://acme-v02.api.letsencrypt.org/directory)
2023/02/16 20:39:36 cmd/web.go:271:listen() [I] [63ee8673-2] HTTP Listener: 0.0.0.0:3000 Closed

It looks like that the service from acme gets a HTTP 400 when requesting the challenge url on
http://git.stubenhocker.tech/.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU

My server configuration looks like this:

[server]

PROTOCOL                = http
REDIRECT_OTHER_PORT     = true
PORT_TO_REDIRECT        = 3001
SSH_DOMAIN              = localhost
DOMAIN                  = git.stubenhocker.tech
HTTP_PORT               = 3000
ROOT_URL                = http://git.stubenhocker.tech
DISABLE_SSH             = true
LFS_START_SERVER        = true
LFS_JWT_SECRET          = [redacted]
OFFLINE_MODE            = false
ENABLE_ACME             = true
ACME_ACCEPTTOS          = true
ACME_DIRECTORY          = /mnt/data/gitea/acmehttps
ACME_EMAIL              = alpha@anonymous.digital

In my firewall I mapped port 443 to 3001 and port 80 to 3000.

In the DNS the domain git.stubenhocker.tech gets it’s IP adress via a CNAME of a dynamic dns.

Any idea what I might miss?

The first failure is using challenge type TLS ALPN 01, which requires port 443 to be open. It looks like port 443 is blocked by the firewall on your machine so it makes sense why it failed.

The second failure is concerning since it was just trying to access your Gitea over port 80 but is getting “Connection refused” (I think you can ignore the “400” part, I think that’s a placeholder and Let’s Encrypt’s servers are not actually getting any HTTP data). I would look into if your firewall is blocking Let’s Encrypt somehow, and also try opening port 443 to see if TLS ALPN 01 will somehow fix things.

Edit: I just re-read your post and saw you have port 443 redirected so I think your focus should be checking if any firewall is preventing Let’s Encrypt access.

@jake Thanks for your reply.

It seems odd, that the acme service can’t access my webserver. The firewall logs show that all traffic is forwared on the correct ports to the gitea endpoint.

However its kind of hard to debug since gitea shuts itself down after getting the acme error so I can’t test if really everything works as expected. Is there a way to tell gitea to not shut down on an error?

At this point it almost looks like that gitea does not serve the needed path (.well-known/acme-challenge/to_c105lSmnS6McLflGyLPZJSHuqFwjK8yxGP28H0LU). Should that path exist after a failed test so I could confirm on filesystem level if the path exists? If yes, where?

edit:
The letsdebug logs also says that the connection is successfull but it seems like the desried path isn’t accessable.