36

Hello everyone,

I've been trying to set up a Mumble voice chat server on my home network using a Debian server. As part of the setup process, I need to obtain an SSL certificate from Let's Encrypt for secure HTTPS access to the server. However, I'm encountering an error when running the Certbot client to request the certificate.

Here's the command I'm running:

sudo certbot certonly -d mydomain.com

But I get the following error message:

Timeout during connect (likely firewall problem)

I've checked my firewall rules and confirmed that I've opened port 80 as required for the Let's Encrypt verification process. Here's the relevant rule in my ufw configuration:

80/tcp ALLOW Anywhere

Despite this, I'm still getting the timeout error. Has anyone else encountered this issue before? What steps should I take to troubleshoot further?

Thanks in advance for any advice!

all 28 comments
sorted by: hot top controversial new old
[-] witten@lemmy.world 18 points 3 months ago* (last edited 3 months ago)

Since this is on a home network, have you also forwarded port 80 from your router to your machine running certbot?

This is one of the reasons I use the DNS challenge instead... Then you don't have to route all these Let's Encrypt challenges into your internal network.

[-] someoneFromInternet@lemmy.ml 2 points 3 months ago
[-] scott@lem.free.as 4 points 3 months ago

You don't need UDP on port 80 forwarded through. HTTP is TCP only.

[-] domi@lemmy.secnd.me 2 points 3 months ago

HTTP/3 is UDP as well but only on port 443.

[-] witten@lemmy.world 3 points 3 months ago

Maybe...? I'm not familiar with that router software, but it looks plausible to me...

[-] epyon22@programming.dev 10 points 3 months ago

Many home ISPs block port 80 and 25. You should be able to Google that and confirm. If that's the case you'll have to use a different method.

[-] webhead@lemmy.world 6 points 3 months ago

This is the answer. Pretty much every ISP blocks 80 They say it is because worms use it blah blah but it is exactly what you think. They don't want you running a web server. You're probably going to have to do the DNS challenge instead.

[-] someoneFromInternet@lemmy.ml 1 points 3 months ago
[-] epyon22@programming.dev 3 points 3 months ago

Google search "Does block port 80"

[-] someoneFromInternet@lemmy.ml 1 points 3 months ago

ISP said that it does not block port 80

[-] kevincox@lemmy.ml 2 points 3 months ago

Try something like https://www.webpagetest.org/ or any other "proxy" service to confirm for youself if it is publicly accessible.

[-] qprimed@lemmy.ml 8 points 3 months ago

are you actually running a web server on that host? iirc, certbot will place a temporary token to be served by your web server (Apache, etc.) to show that you actually control the domain you are requesting a cert for.

I switched to DNS based retrieval as soon as let's encrypt offered it, so its been years since I retrieved certs via http.

[-] someoneFromInternet@lemmy.ml 1 points 3 months ago

actually I'm not hosting any web servers currently )

[-] qprimed@lemmy.ml 3 points 3 months ago

if you are using http cert retrieval, certbot needs a place put the temp. token to authenticate your contrrol of the domain your are creating a certificate for. usually that will be the same webserver you want to serve the certificate from.

if you are not running an actual weberver on port 80 that certbot can insert a token for, certbot cannot complete.

this is, of course, in addition to other possible issues such as ISP port blocking - but without a web server listening on TCP/80, you will have to use other authorization methods (like DNS) to generate a cert.

[-] someoneFromInternet@lemmy.ml 2 points 3 months ago

what would you recommend to a newbie?

[-] atzanteol@sh.itjust.works 5 points 3 months ago* (last edited 3 months ago)

Easiest is probably "certbot --standalone" which lets certbot use its embedded webserver.

Otherwise nginx and apache httpd are common and reasonable options.

[-] qprimed@lemmy.ml 2 points 3 months ago

heh, forgot about the standalone web server in certbot. thats a good ephemeral option.

[-] qprimed@lemmy.ml 3 points 3 months ago

if you are able to run a public web server, then certificate issuance via certbot http challenge works pretty well. the web server can serve a really simple static page with little to nothing on it - but of course its another potential vector into your network.

if your public domain DNS makes use of a supported dns provider or you run your own publically accessible dns server, then dns certbot challenges are great and more flexible than http.

others may suggest neat work arounds for the http challenge issue, but if you have access to a supported dns service I would look at that option. certbot has helpers for quite a few public services as well as support for self hosted dns servers. I run my own public dns servers, so thats the option I chose and use certbot hooks, cron and bash scripts to rsync the updated carts to the propr hosts for the various services I run privately and publicly.

[-] valkyre09@lemmy.world 3 points 3 months ago

I use letsencrypt a lot, if firewalls are an issue I’ll use dns authentication.

If you are struggling and need a quick fix, the free tier of zero ssl will do a similar thing

https://zerossl.com/

I used it to get a cert for my printer

[-] Kid_Thunder@kbin.social 3 points 3 months ago* (last edited 3 months ago)

Sounds like you have nothing listening on port 80 that resolves for your domain for Let'sEncrypt to verify that you own the domain. You need a webserver listening on port 80 and that Certbot can access if you're using the http method.

Basically you're forwarding traffic to port 80 but there's nothing on port 80.

[-] hperrin@lemmy.world 3 points 3 months ago

Check your router and see if you’ve forwarded the port to your server.

[-] elmicha@feddit.de 2 points 3 months ago

You can use your phone with mobile connection (not WiFi) to check if it can see the file that you made available on your web server.

[-] Decronym@lemmy.decronym.xyz 2 points 3 months ago* (last edited 3 months ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
HTTP Hypertext Transfer Protocol, the Web
IP Internet Protocol
TCP Transmission Control Protocol, most often over IP
UDP User Datagram Protocol, for real-time communications
nginx Popular HTTP server

5 acronyms in this thread; the most compressed thread commented on today has 15 acronyms.

[Thread #586 for this sub, first seen 10th Mar 2024, 17:05] [FAQ] [Full list] [Contact] [Source code]

[-] Ebby@lemmy.ssba.com 2 points 3 months ago

Http is port 80, but https is port 443. I'd try opening that too.

[-] Plavatos@sh.itjust.works 4 points 3 months ago

In this situation certbot is using 80 for a challenge/response test to have the host validate itself as the source.

[-] Ebby@lemmy.ssba.com 2 points 3 months ago

Ah, certbot might be a little different then my system. Mine begins the process of renewing the let's encrypt cert on port 80 and switches to 443 to finish. I have to have both open.

[-] Plavatos@sh.itjust.works 2 points 3 months ago* (last edited 3 months ago)

There is another way, I thought. Seem to recall certbot offering it when failing here. If you want more details I can dig into it but it has you create a file in a .well-known and it'll go check for it there.

Edit: as others mentioned the prerequisite here is that you're also listening on port 80 somewhere.

Also, don't forgot let's encrypt will time you out if you ping too often.

this post was submitted on 10 Mar 2024
36 points (92.9% liked)

Selfhosted

37741 readers
830 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS