Problem renewing the certificate

yumibad commented 2 months ago

I'm using jitsi version 9457-2 and the acme version is v3.0.7. I tried to update the certificate, but without success. I saw that cron ran ("/config/acme.sh"/acme.sh --cron --home "/config/acme.sh" > /dev/null) Then I do a "docker-compose down" and then " docker-compose up -d", but the certificate does not renew. Does anyone know how to solve this problem?

saghul commented 2 months ago

The certificate is not renewed unless necessary, why do you need to force it?

yumibad commented 1 month ago

There was 1 day left before the certificate expired, so I was trying to force the renewal. The other times I managed to renew with a few days left.

saghul commented 1 month ago

That's odd. Do you have the output of the container when it ran? Any logs in the web folder?

pabitrabiswal commented 1 month ago

Failed to obtain a certificate from the Let's Encrypt CA. Exiting. [cont-init.d] 10-config: exited 1. [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01-set-timezone: executing... [cont-init.d] 01-set-timezone: exited 0. [cont-init.d] 10-config: executing... /opt / [Sat Jun 29 09:42:22 UTC 2024] Installing to /config/acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installed to /config/acme.sh/acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installing alias to '/root/.profile' [Sat Jun 29 09:42:22 UTC 2024] OK, Close and reopen your terminal to start using acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installing cron job 30 11 "/config/acme.sh"/acme.sh --cron --home "/config/acme.sh" > /dev/null [Sat Jun 29 09:42:22 UTC 2024] Good, bash is found, so change the shebang to use bash as preferred. [Sat Jun 29 09:42:22 UTC 2024] OK / [Sat Jun 29 09:42:23 UTC 2024] Using CA: https://acme.zerossl.com/v2/DV90 [Sat Jun 29 09:42:23 UTC 2024] Run pre hook:'if [[ -d /var/run/s6/services/nginx ]]; then s6-svc -d /var/run/s6/services/nginx; fi' [Sat Jun 29 09:42:23 UTC 2024] Standalone mode. [Sat Jun 29 09:42:23 UTC 2024] Single domain='meet.dashoapp.com' [Sat Jun 29 09:42:24 UTC 2024] Getting domain auth token for each domain [Sat Jun 29 09:42:27 UTC 2024] Getting webroot for domain='meet.dashoapp.com' [Sat Jun 29 09:42:28 UTC 2024] Verifying: meet.dashoapp.com [Sat Jun 29 09:42:28 UTC 2024] Standalone mode server [Sat Jun 29 09:42:30 UTC 2024] Processing, The CA is processing your order, please just wait. [Sat Jun 29 09:50:20 UTC 2024] meet.dashoapp.com:Timeout [Sat Jun 29 09:50:20 UTC 2024] Please add '--debug' or '--log' to check more details. [Sat Jun 29 09:50:20 UTC 2024] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh [Sat Jun 29 09:50:20 UTC 2024] Run post hook:'if [[ -d /var/run/s6/services/nginx ]]; then s6-svc -u /var/run/s6/services/nginx; fi' Failed to obtain a certificate from the Let's Encrypt CA. Exiting. [cont-init.d] 10-config: exited 1.

pabitrabiswal commented 1 month ago

i am getting this error whle trying to configure jitsi on docker ..web container is not able to get a valid lets encrypt ca ..while hostname is associated on ip and i am able to ping it as well. Failed to obtain a certificate from the Let's Encrypt CA. Exiting. [cont-init.d] 10-config: exited 1. [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01-set-timezone: executing... [cont-init.d] 01-set-timezone: exited 0. [cont-init.d] 10-config: executing... /opt / [Sat Jun 29 09:42:22 UTC 2024] Installing to /config/acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installed to /config/acme.sh/acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installing alias to '/root/.profile' [Sat Jun 29 09:42:22 UTC 2024] OK, Close and reopen your terminal to start using acme.sh [Sat Jun 29 09:42:22 UTC 2024] Installing cron job 30 11 "/config/acme.sh"/acme.sh --cron --home "/config/acme.sh" > /dev/null [Sat Jun 29 09:42:22 UTC 2024] Good, bash is found, so change the shebang to use bash as preferred. [Sat Jun 29 09:42:22 UTC 2024] OK / [Sat Jun 29 09:42:23 UTC 2024] Using CA: https://acme.zerossl.com/v2/DV90 [Sat Jun 29 09:42:23 UTC 2024] Run pre hook:'if [[ -d /var/run/s6/services/nginx ]]; then s6-svc -d /var/run/s6/services/nginx; fi' [Sat Jun 29 09:42:23 UTC 2024] Standalone mode. [Sat Jun 29 09:42:23 UTC 2024] Single domain='meet.dashoapp.com' [Sat Jun 29 09:42:24 UTC 2024] Getting domain auth token for each domain [Sat Jun 29 09:42:27 UTC 2024] Getting webroot for domain='meet.dashoapp.com' [Sat Jun 29 09:42:28 UTC 2024] Verifying: meet.dashoapp.com [Sat Jun 29 09:42:28 UTC 2024] Standalone mode server [Sat Jun 29 09:42:30 UTC 2024] Processing, The CA is processing your order, please just wait. [Sat Jun 29 09:50:20 UTC 2024] meet.dashoapp.com:Timeout [Sat Jun 29 09:50:20 UTC 2024] Please add '--debug' or '--log' to check more details. [Sat Jun 29 09:50:20 UTC 2024] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh [Sat Jun 29 09:50:20 UTC 2024] Run post hook:'if [[ -d /var/run/s6/services/nginx ]]; then s6-svc -u /var/run/s6/services/nginx; fi' Failed to obtain a certificate from the Let's Encrypt CA. Exiting. [cont-init.d] 10-config: exited 1.

saghul commented 1 month ago

Do you have both ports 80 and 443 open and pointing to the server?

pabitrabiswal commented 1 month ago

Yes both ports 80 and 443 are open on the VM and pointing to the web server. But still its not able to generate the certificates. Checking inside it i think theres some process called socat using port 80 inside web container.

saghul commented 1 month ago

Yes socat is what acme.sh is using

saghul commented 1 month ago

Does this only happen when renewing or also when you wipe the config directory and start anew?

pabitrabiswal commented 1 month ago

No.. I faced this issue while installing jitsi from scratch. Both with the latest as well as the stable version.

saghul commented 1 month ago

Hum that's odd. I'll try again and see if I can repro.

I suppose your domain is correctly configured to point to the public IP of your server, right?

pabitrabiswal commented 1 month ago

Yes domain is correctly pointing to my VM's IP. I have verified the same .. Let me know if you want the logs too . I could provide that f that would be helpful

H-A-L-I-S commented 1 month ago

I noticed, that this issue came after the ZeroSSL change. Older versions of Jitsi with Letsencrypt are not affected (for example 9364-1).

As a general mention: it is still called Letsencrypt in the config files and partially in the logs. This extended the problem-search a lot by confusing me at first :D

Is there a way to test the latest version with a different CA?

saghul commented 1 month ago

You can try modifying the web container and pass this setting: https://github.com/acmesh-official/acme.sh/wiki/Change-default-CA-to-ZeroSSL

H-A-L-I-S commented 1 month ago

Thank you very much for the link. It answers a lot of question:

Why did you not put that change into changelog? Answer: It was not done by you, but by acme update indirectly.
Why so few people have any issues? Answer by quote: This change will only affect the newly created(issued) certs after August-1st (with v3.0), any pre-existing certs will still be renewed automatically against the current CA.
What can user do to workaround? Answer: Either install older version and then update, or run the following command in the container acme.sh --set-default-ca --server letsencrypt and restart the container. Disclaimer: This will not fix issues related to closed ports.

Will test later and report, if it worked

saghul commented 1 month ago

Why did you not put that change into changelog? Answer: It was not done by you, but by acme update indirectly.

Yeah, me issed that :-/

2. Why so few people have any issues? Answer by quote: This change will only affect the newly created(issued) certs after August-1st (with v3.0), any pre-existing certs will still be renewed automatically against the current CA.

Not sure that is the case... I started from scratch on one of my environments (wiping away .jitsi-meet-cfg) and thus it started fresh with ZeroSSL.

3. What can user do to workaround? Answer: Either install older version and then update, or run the following command in the container acme.sh --set-default-ca --server letsencrypt and restart the container. Disclaimer: This will not fix issues related to closed ports.

I'd be rusprised it's a ZeroSSL specific error, since acme.sh users would have noticed I guess. Maybe there is some bug in the way we use it (standalone).

timoschwarzer commented 1 month ago

Running /config/acme.sh/acme.sh --set-default-ca --server letsencrypt --home "/config/acme.sh" in the web container and restarting it works as a workaround.

saghul commented 1 month ago

I'd take a PR allowing the server to be configurable, if you're up for it.

timoschwarzer commented 1 month ago

I think we'd need to find the root cause first. Reading the comments above suggests that this not only happens after upgrades but also for fresh installs. Another question is why it even tries to use ZeroSSL despite the current certificate being issued by Lets Encrypt. The acme.sh docs clearly state that it should keep using Lets Encrypt in that case.

saghul commented 1 month ago

Agreed. The last thing might be related to the major version update, so I'm not sure.

H-A-L-I-S commented 1 month ago

I'd be rusprised it's a ZeroSSL specific error, since acme.sh users would have noticed I guess.

I saw issue in their Git. But hard to tell, if users just forgot to open closed ports.

I can confirm that after updating to the latest jitsi version the following command renewed the cert without issue:

/config/acme.sh/acme.sh --renew --force -d your.domain.com --home "/config/acme.sh"

This (probably) means that updating from older version or running @timoschwarzer 's command workarounds the issue.

Some P.S.: Not that my opinion matters on your project, but just mentioning the obvious: It probably makes sense to release a hotfix by changing default CA back to letsencrypt

H-A-L-I-S commented 1 month ago

I run a fresh copy of Jitsi in a new folder and copied the .env there. This is error message zerossl gives, when opening the link to zerossl provided in the logs:

{"type":"urn:ietf:params:acme:error:malformed","status":405,"detail":"The request message was malformed"}

Cropped part of the log:

web-1      | [Fri Jul 19 19:36:33 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:36:48 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:36:48 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:36:48 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:37:03 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:37:04 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:37:04 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:37:19 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:37:19 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:37:19 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:37:34 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:37:35 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:37:35 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:37:50 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:37:51 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:37:51 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:38:06 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:38:06 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:38:06 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:38:21 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:38:22 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:38:22 UTC 2024] Retry after: 15
web-1      | [Fri Jul 19 19:38:37 UTC 2024] Polling order status: https://acme.zerossl.com/v2/DV90/order/wFVsR5SN6jIfA6ebV8tJAQ
web-1      | [Fri Jul 19 19:38:37 UTC 2024] Order status is processing, lets sleep and retry.
web-1      | [Fri Jul 19 19:38:37 UTC 2024] Retry after: 15

This log is somehow different from the log which I had before and which got posted above:

[Sat Jun 29 09:44:35 UTC 2024] Processing, The CA is processing your order, please just wait. (1/30)
[Sat Jun 29 09:44:38 UTC 2024] Pending, The CA is processing your order, please just wait. (2/30)
[Sat Jun 29 09:44:41 UTC 2024] Pending, The CA is processing your order, please just wait. (3/30)
[Sat Jun 29 09:44:45 UTC 2024] Pending, The CA is processing your order, please just wait. (4/30)
[Sat Jun 29 09:44:48 UTC 2024] Pending, The CA is processing your order, please just wait. (5/30)
[Sat Jun 29 09:44:51 UTC 2024] Pending, The CA is processing your order, please just wait. (6/30)

(log copied from @yumibad 's message above)

jitsi / docker-jitsi-meet

Problem renewing the certificate #1834