Let's encrypt


It’s the first time I try to use Let’s Encrypt on Debian.

I get this error:

# /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
This script will:
- Need a working DNS record pointing to this machine(for domain meet.mydomain.org)
- Download certbot-auto from https://dl.eff.org to /usr/local/sbin
- Install additional dependencies in order to request Let’s Encrypt certificate
- If running with jetty serving web content, will stop Jitsi Videobridge
- Configure and reload nginx or apache2, whichever is used

You need to agree to the ACME server's Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]: vdipaola@hmanacor.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for meet.mydomain.org
Using the webroot path /usr/share/jitsi-meet for all unmatched domains.
Waiting for verification...
Challenge failed for domain meet.mydomain.org
http-01 challenge for meet.mydomain.org
Cleaning up challenges
Some challenges have failed.

 - The following errors were reported by the server:

   Domain: meet.mydomain.org
   Type:   unauthorized
   Detail: Invalid response from
   []: 404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

What doe sit mean exactly?.
My public DNS A record has the right public IP address.
My local DNS A record has the private IP address of this server.
In any case I added the public IP address for meet.mydomain.org in /etc/hosts.

Why isn’t it “writing” the challenge token on the server?

This must be trivial because I don’t see anyone else reporting an error message like mine.


You tried latest stable right, there were some bugs in nginx configs we addressed in latest packages, which soon will hit stable. So you better start over with those.

same problem, i make the installation following by the basic installion video on youtube, seams the problem is the acme-challenge in the dns record

I’m using latest stable on Debian, but I’m not using nginx. I’m using Apache.

I solved my Let’s Encrypt problem here:
forum post

@damencho is this issue solved in the latest stable? I also get the same error, although i can ping mydomain. Cf. Quick-install jitsi-meet on debian 10 with nginx


I just tried using the latest LetsEncrypt stable installer script for with Apache2. The Certbot domain cert verification challenge fails.

This issue is caused by the default Apache2 vhosts config <000-default.conf> being simultaneously active with the jitsi-generated vhosts config file. To fix the issue, the Apache2 default config first needs to be disabled. This can be done by running the following command:

a2dissite 000-default

Then re-run:

The LetsEncrypt domain challenge will then complete correctly.

Recommend adding the above Apache2 a2dissite command to the LetsEncrypt installer script to make sure the default Apache2 vhosts config is disabled before calling the Certbot process.


1 Like

FYI, I’ve got the same issue on Ubuntu 18.04 [right now]

I’m installing the last (and fresh) stable Jitsi-meet Version (uploaded few hours ago).

Issue is reported from nginx w/ a “404 not found” page, as answer to the HTTP get /.well-known/acme-challenge/xxxx requests coming from 4 clients (3 from amazonaws and the last one letsencrypt).

A few warning/error are also present (after installation) on the logs of:

jicofo: connection refused on localhost ports 5222 and 5347
jvb: connection refused on localhost:5222
prosody: error binding https: no key in SSL/TLS config for port 5281
Maybe, are they are consequently related to this topic ?

… i’ve been following step by step the Jitsi-meet Quick Install guide.

As suggested by Paola, I’ve update the already installed “certbot”.
For me, actually no way to overcome this issue.

Check the nginx configuration. In my case it had errors:

root@meet:~# nginx -T
nginx: [warn] invalid value "TLSv1.3" in /etc/nginx/sites-enabled/meet.domain.io.conf:25
nginx: configuration file /etc/nginx/nginx.conf test failed

Removing the TLSv1.3 option from line 25 solved the problem.