Timeout during connect - But Everything Looks Good (I think)

Help
1

First off, I'm rather new at this. So please forgive me if I misspeak. Also, I apologize for the wall of text. The 'certbot' output is rather lengthy.

I'm trying to set up a web server that is publicly accessible. I'd like to secure it with HTTPS. This web server is on an HSTS domain (access.mfgs.dev). Because I'm new, and HSTS may impact my learning curve, I've also have a non-HSTS domain (access.mfgs.me). I've got a basic Apache install, with zero customization, all defaults. I also have the firewalls (iptables & firewalld) either opened up completely or turned off. I'll harden that later.

I've tried a number of 'certbot' runs, and they all come back the same, with "Timeout during connect (likely firewall problem)". However, when I run 'certbot' with '--debug-challenges' I can successfully use this command:

curl http://access.mfgs.dev/.well-known/acme-challenge/VeryLongString
and
curl http://access.mfgs.me/.well-known/acme-challenge/VeryLongString

Both of these return successfully with the contents:

VeryLongString.anotherLongString

Also, for the non-HSTS domain (access.mfgs.me), I am able to open a web browser to the same URL and see the contents of of the file.

I don't know if it's relevant or not, but this is a home computer on a dynamic IP, and both domains are my domains Google Domains as the registrar. Both of these FQDN's are "Dynamic DNS Synthetic Records," and ddclient is updating them frequently with the current IP (even though they haven't changed at all). I have "Port Forwarding" set up on my home router for both 80 -> 80 and 443 -> 443 to my single web server. Both of these FQDN's are pingable, and the non-HSTS one is, at the time of writing this, serving out the default Apache "Testing 123..." web page. So both DNS and routing seem good to me.

I've Googled eleventy-billion different variations of my issue. It seems that the general consensus is if you can get to a point where the '.well-known' file is accessible (which it is), then 'certbot' should work. I'm at my wit's end, and I don't know what else to do. Any help or pointers would be appreciated.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

access.mfgs.dev
access.mfgs.me

I ran this command:

certbot certonly --webroot -w /var/www/html -d access.mfgs.dev,access.mfgs.me --dry-run --test-cert --debug-challenges -v

It produced this output:

Too long, see reply post (new user, I hope I can reply to this post)

My web server is (include version):

Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version):

CentOS Linux release 7.6.1810 (Core)

My hosting provider, if applicable, is:

N/A

I can login to a root shell on my machine (yes or no, or I don't know):

Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 0.31.0

Thank you in advance.

2

Well, the '-v' log was over 32,000 characters long, so here's the non-'-v' version:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for access.mfgs.dev
http-01 challenge for access.mfgs.me
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Press Enter to Continue
Cleaning up challenges
Failed authorization procedure. access.mfgs.dev (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://access.mfgs.dev/.well-known/acme-challenge/3SAzu3BD_u9BjUyZx5e4HKijctHA-Y-JnRauMd2fbHs: Timeout during connect (likely firewall problem), access.mfgs.me (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://access.mfgs.me/.well-known/acme-challenge/h3Dm_Y0fiu9Y1qKVFMcbOVHORhNF1ngIcHWhxuNnrkM: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

3

http://access.mfgs.me/ times out for me.

https://access.mfgs.me/ gets a ā€œConnection refusedā€ error, which is probably correct if itā€™s not blocked by a firewall but isnā€™t running an HTTPS web server yet.

Can you access http://access.mfgs.me/ from outside your local network or ISP? Your ISP might be blocking port 80. Or you might have a firewall or port forwarding misconfiguration.

2 Likes
4

Hi @RussellNS

is this

Host T IP-Address is auth. āˆ‘ Queries āˆ‘ Timeout
access.mfgs.dev A 47.220.176.93 yes 1 0
AAAA yes
www.access.mfgs.dev Name Error yes 1 0

your local ip address? That's the ip that is public visible ( https://check-your-website.server-daten.de/?q=access.mfgs.dev ).

And there is only a timeout:

Domainname Http-Status redirect Sec. G
ā€¢ http://access.mfgs.dev/
47.220.176.93 -14 10.027 T
Timeout - The operation has timed out
ā€¢ https://access.mfgs.dev/
47.220.176.93 -2 1.437 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 47.220.176.93:443
ā€¢ http://access.mfgs.dev/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
47.220.176.93 -14 10.027 T
Timeout - The operation has timed out
Visible Content:

But the https is blocked, looks like a firewall.

2 Likes
5

Okā€¦ so first off, thank you! The ā€œISP might be blocking port 80ā€ gave me one insight into something I was doing wrong this whole time. Apparently even though Iā€™m accessing the webiste over an FQDN that points to my public IP, I assume that some how Iā€™m still routing locally to access it. Thatā€™s why I can reach the website over port 80 (no local firewalls on port 80), but yā€™all couldnā€™t (ISP apparently blocks inbound port 80). And to test this, I just disabled wifi on my phone and tried to bring up the website. Sure enough, I get the same results as yā€™all did. Again, I apologize for my learning curve.

However, I am able to access both https://access.mfgs.dev and https://access.mfgs.me using my phone this way.

So my question is, do I have a recourse using ā€˜certbotā€™ to both obtain and renew a cert using only port 443? Iā€™ve read several posts that ā€˜certbotā€™ requires ports 80 and 443. Is there a way to only use 443? Is there some other workaround?

Again, thank you to everyone in advance!

6

If you want to use http-01 validation, but your ISP blocks port 80, that can't work.

There is a tls-alpn-01 validation, that requires only port 443. But Certbot doesn't support that, acme.sh does.

Or you use dns-01 validation.

1 Like
7

If youā€™re using Google Cloud DNS (and not the free Google Domains DNS), it should be pretty easy to install python2-certbot-dns-google from EPEL and use DNS-01 validation.

1 Like
8

THANK YOU!

@mnordhoff: Of all the reading that I did, I don't know how I didn't see that an ISP could block incoming ports for residential users. I assumed that if I were routing using DNS and the IP connected to the FQDN was external, it made sense that my traffic was going:

Home Computer <-> Internet <-> Cable Modem <-> Website

Instead it was going:

Home Computer -> Internet -> Cable Modem -> Website -> Oh heck, you're local, just talk directly -> Home Computer <-> Website

Also, the Google Cloud DNS mention is great, and thank you for that! However, one of my drivers is to use free tools. So I researched Google Cloud DNS, but when I got to billing, I looked for other tools. But thank you!

@JuergenAuer: I scoured the link you sent about the Challenge types and googled 'acme.sh'. Both of those were exactly what I needed, and I have something that works. In case anyone else has the issues I've had, here's what I did (CentOS):

sudo yum install -y httpd mod_ssl

sudo systemctl enable httpd

sudo curl https://get.acme.sh | sh

sudo source ~/.bashrc

sudo systemctl stop httpd

sudo sudo acme.sh --issue --alpn -d access.mfgs.dev --webroot /var/www/html --keylength 4096 --log

sudo mkdir -p /etc/ssl/your_cert_dir

sudo acme.sh --install-cert --domain access.mfgs.dev --cert-file /etc/ssl/your_cert_dir/your_cert_name.cer --key-file /etc/ssl/your_cert_dir/your_key_name.key --fullchain-file /etc/ssl/your_cert_dir/your_cert_chain.cer --reloadcmd "sudo systemctl restart httpd"

sudo nano -w /etc/httpd/conf.d/ssl.conf

Update these values:

  • SSLCertificateFile /etc/ssl/your_cert_d* ir/your_cert_name.cer
  • SSLCertificateKeyFile /etc/ssl/your_cert_dir/your_cert_key.key
  • SSLCertificateChainFile /etc/ssl/your_cert_dir/your_cert_chain.cer

sudo nano -w /etc/httpd/conf.d/your_website.conf

Update these values:

  • <VirtualHost *:443>
  • SSLEngine on
  • SSLCertificateFile /etc/ssl/your_cert_d* ir/your_cert_name.cer
  • SSLCertificateKeyFile /etc/ssl/your_cert_dir/your_cert_key.key
  • SSLCertificateChainFile /etc/ssl/your_cert_dir/your_cert_chain.cer

sudo systemctl restart httpd

After all that, all the encryption worked, and the website was reachable via HTTPS.

The only thing I haven't done yet is to create a cron job to renew the certificate, however, I have successfully tested the command-line to do it:

acme.sh --renew -d access.mfgs.dev --force

So again, to everyone, thank you!!!

1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.