# Why did Let's Encrypt renewal stop after upgrading Jitsi Docker? > Docker releases stable-11146 and stable-11146-1 could issue certificates but could not renew them because Debian cron required root. [S1][S2][S3] PR #2305 replaced cron with a rootless acme.sh service in stable-11146-2; stable-11248 remains the latest release checked on 2026-10-05. [S2][S3][S4] Upgrade with matching Compose files, preserve the persistent certificate state, then check renewal and the certificate actually served over HTTPS. [S5][S6][S10] Source: https://jitsi.help/troubleshooting/lets-encrypt-renewal-broken-rootless/ Updated: October 5, 2026 Publisher: Jitsi Help (https://jitsi.help/) ## Symptoms On the affected Docker releases, the web container obtains its first certificate, then repeatedly fails to start cron. Eventually HTTPS presents an expired certificate. Issue #2301 records these lines: [S1][S2] ```text web-1 | no crontab for s6 web-1 | seteuid: Operation not permitted ``` Read them from the project directory: [S13] ```bash docker compose logs --tail 200 web ``` Challenge routing can also fail after the scheduler is fixed. [S14] ## Cause The rootless web image runs as UID 1000. Debian cron needs privileges, exits on `seteuid: Operation not permitted`, and s6 starts it again. Initial issuance succeeds because startup calls acme.sh directly. [S2] Stable-11146-2 replaces cron with the `acme-renewal` service and installs acme.sh with `--nocron`. The service waits 60 seconds, then runs `acme.sh --cron --home /storage/acme.sh` every 43,200 seconds, or 12 hours. It renews certificates when due. It disables itself if `DISABLE_HTTPS=1`, `ENABLE_LETSENCRYPT` is not 1, or the installed executable is missing. [S3][S6] State locations in stable-11248 are: [S5][S7] | Purpose | Container path | Host path | |---|---|---| | Client, account and renewal metadata | `/storage/acme.sh` | `${CONFIG}/storage/web/acme.sh` | | Installed chain and key | `/storage/acme-certs/meet.example.com/fullchain.pem`, `/storage/acme-certs/meet.example.com/key.pem` | `${CONFIG}/storage/web/acme-certs/meet.example.com/` | `${CONFIG}/tmp/web-crontabs` was the obsolete cron mount, removed by PR #2305. `${CONFIG}/tmp/web-load-test` remains unrelated to certificate renewal. Startup copies old `/config/acme.sh` and `/config/acme-certs` into storage only when their new destinations do not exist. [S2][S5][S7] ## Fix Before changing either installation, run the first command in Verify and record the served certificate's serial and `notAfter`. [S10] 1. **Docker, affected releases: upgrade the release and its Compose files.** Use the stable-11248 release archive, preserve your `.env`, passwords and existing `CONFIG` directory, and apply the rootless directory migration if upgrading from an older release. Its writable storage must be accessible to UID 1000. [S2][S4][S5][S8] Set this in `.env`, then run the commands from the updated project directory. This recreates services, so schedule a maintenance window. Keep any additional Compose files you normally use in the invocation. [S5][S8][S13] ```ini JITSI_IMAGE_VERSION=stable-11248 ``` ```bash docker compose config --images docker compose pull docker compose up -d --force-recreate docker compose ps ``` The core images must end with `/web:stable-11248`, `/prosody:stable-11248`, `/jicofo:stable-11248` and `/jvb:stable-11248`. Custom Compose deployments need the matching storage mount and port mappings, not just a new web image. [S5] 2. **Docker stable-11248: check renewal prerequisites.** For direct HTTPS termination in the web container, confirm these `.env` settings: [S7][S8] ```ini ENABLE_LETSENCRYPT=1 DISABLE_HTTPS=0 LETSENCRYPT_DOMAIN=meet.example.com LETSENCRYPT_EMAIL=admin@example.com HTTP_PORT=80 HTTPS_PORT=443 ``` After changing these values, recreate web. Restarting alone does not apply environment changes. [S13] ```bash docker compose up -d --no-deps --force-recreate web ``` Public TCP 80 must reach the standalone HTTP challenge. The corrected Compose mapping sends host port 80 to container port 8000, and PR #2300 adds `--httpport 8000`. TLS expiry does not prevent HTTP-01 validation. If an external proxy owns TLS, renew through its certificate manager. [S3][S5][S7][S8][S15] 3. **Docker stable-11248: run a due renewal check first.** Use `/command/with-contenv` to load the service environment, including PATH for its Nginx hooks. Check due renewals and list records: [S6][S13] ```bash docker compose exec -T web /command/with-contenv /storage/acme.sh/acme.sh --cron --home /storage/acme.sh docker compose exec -T web /command/with-contenv /storage/acme.sh/acme.sh --list --home /storage/acme.sh ``` 4. **Docker stable-11248: recover an expired certificate or force one controlled renewal.** After fixing connectivity, select the record backing the served certificate. Use the ECC command below for an `ec-` key length. For an RSA certificate, omit `--ecc`. Renewal uses stored challenge settings and install paths. Its hooks stop and start Nginx, so use a maintenance window and avoid concurrent renewal attempts. [S7][S9] ```bash docker compose exec -T web /command/with-contenv /storage/acme.sh/acme.sh --renew -d meet.example.com --ecc --force --home /storage/acme.sh ``` After successful renewal, restart web to ensure it loads the installed certificate, then run Verify. Preserve the ACME account and certificate directories. Repeated forced requests are not a substitute for fixing validation and can encounter CA rate limits. [S7][S9][S13][S15] ```bash docker compose restart web ``` 5. **Debian/Ubuntu packages: identify the installed certificate client.** Docker tags and its cron regression do not apply to the package helper. At `jitsi-meet_11248`, it uses acme.sh under `/opt/acmesh/.acme.sh`, installs `/etc/jitsi/meet/meet.example.com.crt` and the matching `.key`, and saves web-server and coturn reload commands. Run its due-renewal check: [S11] ```bash sudo /opt/acmesh/.acme.sh/acme.sh --cron --home /opt/acmesh/.acme.sh ``` To recover that helper's issuance and installation configuration, use: [S11] ```bash sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh admin@example.com meet.example.com ``` This requests a certificate and configures reload hooks. Older installations actually managed by Certbot should instead test their saved renewal configuration, then renew due certificates: [S11][S12] ```bash sudo certbot renew --dry-run sudo certbot renew ``` ## Verify For Docker stable-11248 and package installs, inspect the endpoint from a machine with OpenSSL 3.0: [S10] ```bash openssl s_client -connect meet.example.com:443 -servername meet.example.com /dev/null | openssl x509 -noout -issuer -dates -serial openssl s_client -connect meet.example.com:443 -servername meet.example.com /dev/null | openssl x509 -noout -checkend 0 openssl s_client -connect meet.example.com:443 -servername meet.example.com -verify_hostname meet.example.com -verify_return_error