Timeout contacting

Hi.

I’ve been trying to use certbot to generate certficates for my Raspberry PI server running NginX.

I have forwarded ports 80 and 443 to 10080 and 10443 respectively on my router and I can indeed reach my PI from the outside world.

Yet when running certbot in webroot mode I get Timeout error.

The same happens when I try standalone mode (after shutting down NginX of course).

What could be the problem?

Just to clarify: did you forward ports 80 and 443 on your router to 10080 and 10443 on the Pi?

If so, you may need to add the --http-01-port or --tls-sni-01-port options to the certbot command to tell it what port to respond on.

Or did you forward ports 10080 and 10443 on the router to 80 and 443 on the Pi? If so, that won’t work; Let’s Encrypt will only connect on port 80 or 443 to verify the challenges. If you can’t forward either of those ports to your Pi, you’ll have to use the DNS challenge instead.

It’s the second case. NginX runs on ports 80 and 443 locally. The router forwards them to 10080 and10443 outside my LAN.

I can temporarily forward 80 to 80, just for the certificate negotiation by certbot.

The problem would arise then in the future, when renewing the certificate via crontab like I read in the docs. I already have another web server running on 80 and 443 on another machine.

To issue or renew certificates via http-01 or tls-sni-01 validation, you must use port 80 and 443. There’s no way around it.

The other available challenge is dns-01.

One workaround you could try is for the first web server (that receives the requests on 80 and 443) to proxy requests to the second web server (that receives requests on 10080 and 10443).

For example:

# on the first server's nginx
server {
  listen 80;
  server_name second-domain.com;

  location /.well-known/acme-challenge/ {
    proxy_pass http://10.10.10.2/.well-known/acme-challenge/; # where 10.10.10.2 is the internal IP of the second server
    proxy_set_header Host $host;
  }
}
2 Likes

Unfortunately, the first servr can not be touched or impacted (it’s an apache, not a NginX by the way).

I have to find a way that only impacts configuration changes on the RaspberryPI NginX server.

In that case, there are no solutions to your problem.

Your choices are to either complete the DNS-based challenge (dns-01), or not use Let’s Encrypt at all.

How does the DNS challenge work? I tries reading the docs but I’m not sure I understood the correct procedure.

To validate www.example.com, you would create a TXT record called _acme-challenge.www.example.com with a special value provided by your ACME client.

You can delete the record as soon as you’ve validated.

As always, getting a new authorization to renew requires setting a different record value.

You can use a CNAME or delegation to point it elsewhere.

It works best when your DNS provider can be controlled by your ACME client programmatically, but it can be done manually as well.

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