Lets Encrypt timeout during connect

Hello there.

I just had to reinstall Jitsi on Ubuntu Server 20.04.
With previous installation I had not problems at all but, this time, no way to generate the Lets Encrypt certificate.

As described in the Self Hosting Guide - Debian/Ubuntu server I’m attempting to generate a Lets Encrypt certificate by running script sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh.

Well, I’m returned the following:
Domain: jitsi.xxxxx.it
Type: connection
Detail: Fetching
http://jitsi.xxxxx.it/.well-known/acme-challenge/xxxxx
Timeout during connect (likely firewall problem)
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. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you’re using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

No ideas what to do considering that everything is the same as before, DNS record included.

Any suggestions?

Regards

well, perform the checks. Something has changed that you are not aware of. Additionally you can (should) do a full test by setting a dummy file in the acme-challenge directory and trying to access it from the outside of your network (using a tethered phone if you have nothing else).

Sorry I’m not clear…

the checks are the following ones:

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. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you’re using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

I may have the gap found.

Now I have the certificate and Jitsi fully working from the Internet.

By the way, I need it to work also on a closed network with no Internet access.
On this network I can’t use the certificate related to my Internet public IP, because people from closed network need to use another private IP address to reach Jitsi, so that certificate is invalidated.
Viceversa, I think I cannot create a certificate for a private IP.

Well, for unknown reasons audio and video streams don’t start with invalidated certificate, but also with self-signed certificate.
I’m not clear about the failure with self-signed certificate, as is it created by Jitsi’s install script.

Regards

Hi,
do you have the server in DMZ (NAT)?
If so, you read the Advanced configuration section.

If you also have to use the server internally and you don’t want to go through the public ip, you create a pinpoint zone in the private DNS with the private IP of the server.

regards

webrtc need a valid certificate, that’s why video and sound don’t work without the certificate, if you use Jitsi-meet with a private IP address you need either a private DNS server that will serve internal clients with the private IP address when they try to use the DNS name (that’s called a split DNS) or if you have very few clients just add an entry in the hosts file for all internal clients.

Yea, that’s exactly how I’ve just been doing and it seems to work.
I’ll test further.

Regards

Jitsi also works with a certificate generated internally by the server.
Before implementing the structure, also clustered with recording and live streaming services in production, i tested everything locally with certificates generated by the server and everything worked with some small changes that were not needed in production because the certificate is a valid certificate.

Regards

yes that’s fine if you use only internal clients - if you use internal and external clients the only solution is to use public certificate with internal clients.

It seems stable and I’ll let it work this way for some time.
In the future, maybe I’ll close access from Internet.
I think I’ll have to leave port 80 open to allow certificate renewal.

Regards.

Yes yes, right!

Open doors: 80, 443, 10000