Let's Encrypt certificate

[carlososuna86]

I am looking at the Let's Encrypt implementation.

Should we generate a new certificate every time the container is booted? Because validating /etc/letsencrypt/live/$LETSNECRYPT_DOMAIN/fullchain.pem will fail, since the container will not keep files that are not in volumes, after the container is shut down.

[saghul]

Should we generate a new certificate every time the container is booted?

Why not?

Because validating /etc/letsencrypt/live/$LETSNECRYPT_DOMAIN/fullchain.pem will fail, since the container will not keep files that are not in volumes, after the container is shut down.

True that, but since we generate if on every boot it will be there when needed.

Are you running into specific issues?

[carlososuna86]

Actually, I am. Let's Encrypt allows only 5 certificates for the same domain per week. If you are testing or debugging your solution, you may blow that limit easily.

After I tried testing something yesterday, I got this error message:
An unexpected error ocurred: There were too many requests of a given type :: Error finalizing order :: too many certificates already issued for exact set of domains: $LETSENCRYPT_DOMAIN: see https://letsencrypt.org/docs/rate-limits/

[sapkra]

For testing purposes you can use staging certificates instead. I think they should work fine with jitsi.
https://letsencrypt.org/docs/staging-environment/

@saghul Are untrusted certificates a problem for jitsi or maybe the mobile app?

But yes when you deploy your application multiple times a week to production it may be a problem.

[carlososuna86]

A solution to easily integrate the staging environment to the init script would be to set an environment variable that will switch the --dry-run flag when calling the certbot.

[saghul]

Actually, I am. Let's Encrypt allows only 5 certificates for the same domain per week. If you are testing or debugging your solution, you may blow that limit easily.

Gotcha. We could store the certs in the volume and assume the cron job will renew them on time. We could also have an env variable to force-renew on startup.

For testing purposes you can use staging certificates instead. I think they should work fine with jitsi.
https://letsencrypt.org/docs/staging-environment/

@saghul Are untrusted certificates a problem for jitsi or maybe the mobile app?

Untrusted certs won't work on mobile. We already get tons of bogus reports from people trying to use self-signed certs on mobile, so I'd rather explore other solutions that don't involve untrusted certs.

@carlososuna86 @sapkra so how about this: we start storing the certs in the data volume, then if some LETSENCRYPT_FORCE_RENEW is set we renew on startup, even if the files are there. Otherwise the cron job will do the needful.

If you like the above, a PR would be most welcome, as I won't have time to work on it this week.

[saghul]

Fixed in the dev branch.

[dg-otrs]

Hey,

I run into the same issue again because of testing. The reason is based on the docu, which says: "IMPORTANT: At the moment, configuration is not regenerated on every container boot, so if you make any changes to your .env file, make sure you remove the configuration directory before starting your containers again". See https://github.com/jitsi/docker-jitsi-meet#configuration

Please update the docu, to watch out for the certificate. So it wont be deleted if necessary.

Thx

Cheers

dennis

[phptek]

For anyone finding this in the future, LE say that there's no way to clear the status of your domain-set until the 7 days "sliding window" has elapsed, regardless of how you spell, or arrange the domains in the certbot command. However, if like me, you have a spare domain kicking around that you haven't yet added to the cert, add that and re-run the command. This worked for me.