An expired certificate is one of the few Jitsi failures that takes down every meeting at once. Browsers refuse the page, the mobile apps refuse to connect, and it always seems to happen on a Monday morning. Renewal is meant to be automatic. Here is how it works, why it quietly stops, and how we handle it on setups with more than one shard.
Check when your certificate expires
Start with the certificate your users actually get, not the file on disk:
echo | openssl s_client -connect meet.example.com:443 -servername meet.example.com 2>/dev/null \
| openssl x509 -noout -issuer -enddateLet's Encrypt certificates last 90 days and are normally renewed around 30 days before notAfter. If the date is less than three weeks away, renewal has probably been failing for a while.
No more reminder emails
SSL certificate renewal process on a single Jitsi server
How renewal works depends on how the certificate was created.
Installed with the Jitsi Let's Encrypt option (acme.sh)
Current Jitsi packages set up Let's Encrypt with acme.sh, installed under /opt/acmesh. It issues the certificate using the web root /usr/share/jitsi-meet, copies it to /etc/jitsi/meet/, and adds a daily cron job that renews it and reloads nginx.
# list certificates and their next renewal date
sudo /opt/acmesh/.acme.sh/acme.sh --list --home /opt/acmesh/.acme.sh
# renew now, even if it is not due yet
sudo /opt/acmesh/.acme.sh/acme.sh --renew -d meet.example.com --force --home /opt/acmesh/.acme.shIf the certificate was never set up, or you replaced it by hand, rerun Jitsi's script: sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh. It installs acme.sh, issues the certificate and wires up renewal.
Older installs with certbot
Servers set up before Jitsi switched to acme.sh often use certbot. Test the renewal without touching the live certificate:
sudo certbot renew --dry-run
systemctl list-timers | grep certbot # is the renewal timer running?Why Jitsi certificate renewal fails
| Symptom | Usual cause |
|---|---|
| Timeout during the challenge | TCP port 80 closed in the firewall or security group. Meetings only need 443, so it gets closed "for security". |
| Wrong IP in the challenge | DNS points somewhere else: a new Elastic IP, a CDN, or a second shard. |
| Renewed, but browsers still see the old one | nginx was not reloaded, or the certificate was copied to the wrong path. |
| Web works, calls through TURN fail | coturn uses its own copy of the certificate and was not restarted. |
Port 80 is the big one. Keep it open and redirect it to HTTPS in nginx, which the Jitsi config already does. Our list of ports Jitsi Meet needs includes it for exactly this reason. If you run coturn on the same domain, add a coturn restart to the renewal's reload command; setting up a TURN server for Jitsi Meet shows where coturn reads its certificate.
Renewing SSL on a multi-shard Jitsi setup
Larger setups run two or more shards, each with its own HAProxy or Meet server, behind a single domain. That breaks the HTTP challenge: Let's Encrypt connects to whichever shard DNS gives it, and that may not be the one that asked.
Option 1: one shard at a time with Route 53 weights
This is the process we used in 2021, and it still works when the shards sit behind weighted Route 53 records:
- Set shard 2's record weight to 0, so all traffic, including the challenge, goes to shard 1.
- Wait for the old DNS answers to expire (the record's TTL), then run the certificate script on shard 1's server.
- Swap: shard 1 to 0, shard 2 back up, wait for the TTL, run the script on shard 2.
- Set both weights back to their normal values. Forget this step and one shard carries every meeting.
It works, but it is manual, every 60 days, and step 4 is easy to miss. Only do it outside busy hours, because the shard you drain still hosts running conferences until they end.
Option 2: DNS-01 challenge through Route 53
Better. With the DNS challenge, Let's Encrypt checks a TXT record instead of connecting to the server, so it doesn't matter which shard DNS points at. acme.sh has a Route 53 plugin (--dns dns_aws); give the instance an IAM role allowed to change that one hosted zone, and each shard renews on its own, with no weight changes.
Option 3: terminate TLS on the load balancer
If the web traffic already passes through an AWS Application or Network Load Balancer, put an ACM certificate on it. ACM renews by itself and there is nothing on the shards to renew. Media still flows directly to the videobridges on UDP 10000, which doesn't use this certificate.
For Jitsi on Kubernetes, the certificates live in Secrets and the process is different again; see updating SSL certificates in Jitsi Meet and TURN servers on Kubernetes. And if you're still planning how shards fit together, read Jitsi load balancing with multiple videobridges first.
Frequently Asked Questions
Does Jitsi Meet renew its Let's Encrypt certificate automatically?
Yes, if you used the installer's Let's Encrypt option. Current Jitsi packages use acme.sh, which installs a daily cron job and renews the certificate before it expires. Older installs used certbot with its own timer.
Why did my Jitsi SSL certificate renewal fail?
Most often port 80 is closed. Let's Encrypt's HTTP challenge fetches a file over plain HTTP, so the firewall or security group must allow TCP 80 even though meetings run on 443. A changed DNS record or a load balancer in front is the next most common cause.
How do I check when my Jitsi certificate expires?
Run openssl s_client against your domain on port 443 and pipe it to openssl x509 -noout -enddate. It prints the notAfter date of the certificate your users actually receive.
How do I renew SSL on a multi-shard Jitsi setup?
Either renew one shard at a time while DNS sends traffic to the other, or switch to the DNS-01 challenge through Route 53 so every shard can renew without being reachable on port 80. Terminating TLS on an AWS load balancer with ACM removes renewal work entirely.
Will Let's Encrypt email me before my certificate expires?
No longer. Let's Encrypt stopped sending expiry reminder emails in 2025. Monitor the expiry date yourself, for example with an uptime checker that alerts two weeks before notAfter.
