ACME certificate not renewing automatically #11461

New Issue

GiteaMirror · 2025-11-02T09:38:32-06:00

GiteaMirror commented

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

Originally created by @booi on GitHub (Aug 16, 2023).

Description

We use gitea fairly simply using docker to run and use the built-in ACME certificate management to obtain and renew certificates.

The server has been running for 2+ months with no issues but we received an email from letsencrypt that we had a certificate expiring in 18 days. I think this shouldn't happen as certificates using certmagic should automatically be renewed in the latter third of the certificate period (30 days). I quick openssl s_client ... verified the impending expiration.

I thought maybe it would run later but we're now about 3 days away so I assume it will not automatically renew. I bounced the docker container and gitea immediately attempted to renew the certificate.

Is there a configuration that I missed? Or potentially there's something wrong either with the way we're using certmagic?

app.ini


[server]
APP_DATA_PATH    = /data/gitea
DOMAIN           = MYHOSTNAME.com
ENABLE_ACME      = true
ACME_ACCEPTTOS   = true
ACME_DIRECTORY   = https
ACME_EMAIL       = infra@MYHOSTNAME.com
SSH_DOMAIN       = MYHOSTNAME.com
PROTOCOL         = https
HTTP_PORT        = 3000
ROOT_URL         = https://MYHOSTNAME.com/
DISABLE_SSH      = false
SSH_PORT         = 2222
SSH_LISTEN_PORT  = 22
LFS_START_SERVER = true
LFS_JWT_SECRET   = *************
OFFLINE_MODE     = true

Gitea Version

1.19.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/booi/8fbb67086bc16005e8fd39a8aa10f494

Screenshots

No response

Git Version

2.38.5

Operating System

docker image: gitea/gitea:1.19.3

How are you running Gitea?

docker image gitea/gitea:1.19.3

Database

None

Originally created by @booi on GitHub (Aug 16, 2023). ### Description We use gitea fairly simply using docker to run and use the built-in ACME certificate management to obtain and renew certificates. The server has been running for 2+ months with no issues but we received an email from letsencrypt that we had a certificate expiring in 18 days. I think this shouldn't happen as certificates using certmagic should automatically be renewed in the latter third of the certificate period (30 days). I quick `openssl s_client ...` verified the impending expiration. I thought maybe it would run later but we're now about 3 days away so I assume it will not automatically renew. I bounced the docker container and gitea immediately attempted to renew the certificate. Is there a configuration that I missed? Or potentially there's something wrong either with the way we're using certmagic? app.ini ``` [server] APP_DATA_PATH = /data/gitea DOMAIN = MYHOSTNAME.com ENABLE_ACME = true ACME_ACCEPTTOS = true ACME_DIRECTORY = https ACME_EMAIL = infra@MYHOSTNAME.com SSH_DOMAIN = MYHOSTNAME.com PROTOCOL = https HTTP_PORT = 3000 ROOT_URL = https://MYHOSTNAME.com/ DISABLE_SSH = false SSH_PORT = 2222 SSH_LISTEN_PORT = 22 LFS_START_SERVER = true LFS_JWT_SECRET = ************* OFFLINE_MODE = true ``` ### Gitea Version 1.19.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/booi/8fbb67086bc16005e8fd39a8aa10f494 ### Screenshots _No response_ ### Git Version 2.38.5 ### Operating System docker image: gitea/gitea:1.19.3 ### How are you running Gitea? docker image `gitea/gitea:1.19.3` ### Database None

GiteaMirror added the issue/needs-feedback label 2025-11-02 09:38:32 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@yp05327 commented on GitHub (Aug 16, 2023):

Fetching http://MYHOSTNAME.com/.well-known/acme-challenge/*****************************: Connection refused", "instance": "", "subproblems": []}}

It seems that it is using http protocol to verify your domain. And can not access this url from outside of your server.

I have checked the code. Gitea using http challenge by default:
3e044d2c9f/cmd/web_acme.go (L42-L46)
It seems that Gitea will start a new http server when doing the challenge, and this is the log:

gitea | 2023/08/15 23:30:18 cmd/web_acme.go:113:func1() [I] [64dc0a8a] Running Let's Encrypt handler on 0.0.0.0:80

So did you add a port forward from docker to the host and open 80 port on your host?

@yp05327 commented on GitHub (Aug 16, 2023): > Fetching http://MYHOSTNAME.com/.well-known/acme-challenge/*****************************: Connection refused", "instance": "", "subproblems": []}} It seems that it is using `http` protocol to verify your domain. And can not access this url from outside of your server. I have checked the code. Gitea using http challenge by default: https://github.com/go-gitea/gitea/blob/3e044d2c9fea7c197aa0476e2c9735320c112e03/cmd/web_acme.go#L42-L46 It seems that Gitea will start a new http server when doing the challenge, and this is the log: > gitea | 2023/08/15 23:30:18 cmd/web_acme.go:113:func1() [I] [64dc0a8a] Running Let's Encrypt handler on 0.0.0.0:80 So did you add a port forward from docker to the host and open 80 port on your host?

GiteaMirror commented

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

@booi commented on GitHub (Aug 16, 2023):

Yes, or at least I think I did. The server listens to both 80 and 443 but forwards both to the container port 3000. It's definitely possible this isn't the right way to do it though.

Here's the docker-compose.yaml used to run the container.

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.19.3
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - /mnt/XXXXXX/gitea/data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "80:3080"
      - "443:3000"
      - "2222:22"

@booi commented on GitHub (Aug 16, 2023): Yes, or at least I think I did. The server listens to both 80 and 443 but forwards both to the container port 3000. It's definitely possible this isn't the right way to do it though. Here's the `docker-compose.yaml` used to run the container. ``` version: "3" networks: gitea: external: false services: server: image: gitea/gitea:1.19.3 container_name: gitea environment: - USER_UID=1000 - USER_GID=1000 restart: always networks: - gitea volumes: - /mnt/XXXXXX/gitea/data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "80:3080" - "443:3000" - "2222:22" ```

GiteaMirror commented

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

@yp05327 commented on GitHub (Aug 16, 2023):

forwards both to the container port 3000.

"80:3080"

You are forwarding 80 port to 3080 port (not 3000), but I can not find this port in the server settings you gave.

I can't test this issue now in my local. But I guess maybe you need to add this in app.ini

[server]
REDIRECT_OTHER_PORT = true
; Port the redirection service should listen on
PORT_TO_REDIRECT = 3080

Then the Let's Encrypt handler Server will run in 3080 port.
(It is running in 80 port inside of the docker container now because the default value of PORT_TO_REDIRECT is 80.)

Here is the document:
https://docs.gitea.com/administration/https-setup#setting-up-http-redirection

@yp05327 commented on GitHub (Aug 16, 2023): > forwards both to the container port 3000. > - "80:3080" You are forwarding 80 port to 3080 port (not 3000), but I can not find this port in the `server` settings you gave. I can't test this issue now in my local. But I guess maybe you need to add this in app.ini ``` [server] REDIRECT_OTHER_PORT = true ; Port the redirection service should listen on PORT_TO_REDIRECT = 3080 ``` Then the `Let's Encrypt handler Server` will run in 3080 port. (It is running in 80 port inside of the docker container now because the default value of `PORT_TO_REDIRECT` is 80.) Here is the document: https://docs.gitea.com/administration/https-setup#setting-up-http-redirection ![image](https://github.com/go-gitea/gitea/assets/18380374/92b86c05-78f6-4480-b5c0-85b3ee6f8848)

GiteaMirror commented

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

@booi commented on GitHub (Aug 16, 2023):

@yp05327 you are absolutely correct! Thanks for finding that missing config!

show nothing running on docker host port 80

$ curl localhost 80
curl: (56) Recv failure: Connection reset by peer

added the following to app.ini

REDIRECT_OTHER_PORT = true
PORT_TO_REDIRECT = 3080

restart container

$ docker compose down
$ docker compose up -d

letsencrypt handler running on 3080

gitea  | 2023/08/16 09:43:35 cmd/web_acme.go:113:func1() [I] [64dc9a47] Running Let's Encrypt handler on 0.0.0.0:3080

verify it's exposed

$ curl localhost 80
<a href="https://MYHOSTNAME.com/">Temporary Redirect</a>.

The certificate has a ways to go but I have confidence this resolved the issue. Thanks again!

@booi commented on GitHub (Aug 16, 2023): @yp05327 you are absolutely correct! Thanks for finding that missing config! show nothing running on docker host port 80 ``` $ curl localhost 80 curl: (56) Recv failure: Connection reset by peer ``` added the following to app.ini ``` REDIRECT_OTHER_PORT = true PORT_TO_REDIRECT = 3080 ``` restart container ``` $ docker compose down $ docker compose up -d ``` letsencrypt handler running on 3080 ``` gitea | 2023/08/16 09:43:35 cmd/web_acme.go:113:func1() [I] [64dc9a47] Running Let's Encrypt handler on 0.0.0.0:3080 ``` verify it's exposed ``` $ curl localhost 80 <a href="https://MYHOSTNAME.com/">Temporary Redirect</a>. ``` The certificate has a ways to go but I have confidence this resolved the issue. Thanks again!

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#11461