Use of Failover Router

Help
1

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. crt.sh | 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: nbs.sec-comms.net

I ran this command:
C:\Windows\system32>certbot --webroot -w c:\gemweb\parent certonly -d nbs.sec-comms.net

It produced this output:

Saving debug log to C:\Certbot\log\letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for nbs.sec-comms.net
Using the webroot path c:\gemweb\parent for all unmatched domains.
Waiting for verification...
←[31mChallenge failed for domain nbs.sec-comms.net←[0m
http-01 challenge for nbs.sec-comms.net
Cleaning up challenges
←[31mSome challenges have failed.←[0m
←[1m
IMPORTANT NOTES:
←[0m - The following errors were reported by the server:

Domain: nbs.sec-comms.net
Type: connection
Detail: 82.13.200.226: Fetching
http://nbs.sec-comms.net/.well-known/acme-challenge/RX7Xn-ODeXLNnwGpsrAK01OWYoc9cyU1a96I5_oAhEs:
Timeout during connect (likely firewall problem)

My web server is (include version): Apache 2.4

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

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): 1.8.0

Notes:
http://nbs.sec-comms.net (unencrypted) produces output

I am using a failover router. Sec-comms.net DNS A record is set to 82.13.200.226 and messages addressed to this IP are processed. All responses are given via IP 45.13.7.252 This is not a problem with normal browsers. Does LE look for a response from the ip addresses it sent the challenge to?

2

I cannot reach your domain using HTTP using curl. The Let's Debug test site cannot reach your domain and its test with LE Staging fails with same timeout as your production request.

I don't know how a request from a browser would work any differently than HTTP requests using other tools.

Something is blocking HTTP requests. Are you sure you don't have a firewall or a problem with your network and/or port routing?

From my own test server in an AWS US east coast region

curl -i -m8 http://nbs.sec-comms.net
curl: (28) Connection timed out after 8000 milliseconds

The Let's Debug site is very helpful when setting up new sites

ALSO, the EFF has dropped support for Certbot on Windows as of last month. You should avoid using it for new setups. See another of my posts about that here:

4 Likes
3

Thank you for your most enlightening reply. Tomorrow I will investigate not only why the sight has gone off line, but also the new certificates.

1 Like
4

If your site has multiple IP addresses then they all need to respond in the same way to the same http challenge. If you have a single IP but it's a load balancer to multiple backends then either route all http /.well-known/acme-challenge/ requests to a single server or otherwise ensure they will all respond with the same challenge response.

Often the simplest setup for multiples servers serving the same site is to use DNS validation instead of HTTP challenges, then perform cert renewals from a a single server and distribute the certs to each service that needs it using scripting or things like Windows CCS (centralized certificate store).

As noted your firewall is not currently allowing port 80 or port 443 on that IP, or you have no services running.

[What webserver are you planning to use these certificates with?]

1 Like
5

Thank you both for your comments and recomendations. Followiing these I made many changes but I believe the root problem was a setting on the router. The strange thing is although I now have a certificate, LetsDebug.net still gives me an error :slight_smile: I need to wait until I get my external workstation running so that I can do more extensive checks. In the meentime I will investigate the alternative certification facilities you have mentioned.
Again Thank you. I would never have got this far without your help.
Geoff Marshall

1 Like
6

I see your DNS points to a different IP now.

But, HTTP requests (port 80) still fail from my own test server. And, I also see the Let's Debug tests are timing out which also use HTTP.

HTTPS requests (port 443) work fine and use your new cert.

I am surprised you were able to get a cert unless you used a DNS Challenge (or TLS-ALPN).

2 Likes
7

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