Certbot behind NAT fails even with manual flag

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:

I ran this command:
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges http -d oichman.duckdns.org

It produced this output:

Challenge failed for domain oichman.duckdns.org
http-01 challenge for oichman.duckdns.org
Cleaning up challenges
Some challenges have failed.


  • The following errors were reported by the server:

    Domain: oichman.duckdns.org
    Type: connection
    Detail: Fetching
    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.

I was able to reach the link before I hit the ENTER Key from outside of my network (tried it from my cellphone)

My web server is (include version):
apache - 2.4

The operating system my web server runs on is (include version):
CentOS Linux release 7.7.1908 (AltArch)

My hosting provider, if applicable, is:

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

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

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

Not sure what to tell you - port 80 for sure looks like it's filtered. Other ports seem to work fine ("connection refused").

$ nc -w 10 -vvv 22
nc: connect to port 22 (tcp) failed: Connection refused

$ nc -w 10 -vvv 80
nc: connect to port 80 (tcp) timed out: Operation now in progress
1 Like

can you please retest it
nc -w 10 -vvv 80
Ncat: Version 7.70 ( https://nmap.org/ncat )
NCAT DEBUG: Using system default trusted CA certificates and those in /usr/share/ncat/ca-bundle.crt.
NCAT DEBUG: Unable to load trusted CA certificates from /usr/share/ncat/ca-bundle.crt: error:02001002:system library:fopen:No such file or directory
libnsock nsock_iod_new2(): nsock_iod_new (IOD #1)
libnsock nsock_connect_tcp(): TCP connection requested to (IOD #1) EID 8
libnsock nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 []
Ncat: Connected to
libnsock nsock_iod_new2(): nsock_iod_new (IOD #2)
libnsock nsock_read(): Read request from IOD #1 [] (timeout: -1ms) EID 18
libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 26

Port 80 invariably gives the exact same timeout on every host in your /24, but not any other port.

I’m pretty sure your ISP is filtering it.

1 Like

so can you please remind me the syntax of changing it to a higher port (8080 for example)

You can’t. Let’s Encrypt will only perform HTTP domain validation over port 80, because those are the rules it has to conform to.

If you download another ACME client like https://acme.sh , you could potentially validate the domain over port 443 using ALPN domain validation, which doesn’t seem to be filtered in your case:

acme.sh --issue --alpn -d oichman.duckdns.org

worked like a charm !!!
thank you very much for all your help :slight_smile:


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