Renewal using certonly subcommand

Issuance Tech
1

I created a certificate using the 'certonly' subcommand for another machine. I now need to renew the certificate, however, the authentication process fails because the target machine sits behind a router which has its own web server listening on port 80. This means that certbot can't access the target machine.

Is it possible to specify a different port number for certbot to use for the challenge?

Here's the log of the attempt to renew the certificate:

Blockquote

certbot-auto certonly -d starlightproductions.ddnsfree.com --cert-path ~/certs/starlightproductions.crt
Requesting to rerun /usr/local/bin/certbot-auto with root privileges...
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for starlightproductions.ddnsfree.com
Waiting for verification...
Challenge failed for domain starlightproductions.ddnsfree.com
http-01 challenge for starlightproductions.ddnsfree.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

Blockquote

2

Usually there is a way to re-assign the router's web admin port from 80 to something else, which frees up 80 to be used by port forwarding.

3

By the way, this is often bad OS reporting of different ICMP errors, such as "administratively prohibited" (from firewalls). I wish we had clearer socket-to-application reporting of these distinctions. nmap can seemingly see them and you can also see them with Wireshark. :shark:

(I agree with your interpretation, just complaining about the socket APIs!)

4

And that is the case here—Wireshark confirms that this is ICMP type 3, code 13 ("Communication administratively prohibited").

5

That's probably a good sign (the router denying ingress from the WAN side to its admin server) - as long as @pcameron60 can figure out how to move the router web server to another port, everything should just starting working.

Not really.

You can try use TLS-ALPN which uses port 443 instead, but it's a bit of a pain and not supported by Certbot. acme.sh is one that does support that mode, in case you do want to try it.

A third option is to try and use the DNS challenge. I see that your DDNS domain is operated by Dynu, so you might be able to use acme.sh's Dynu support to issue your certificate: dnsapi · acmesh-official/acme.sh Wiki · GitHub . If you can get this to work, I would definitely recommend it over the TLS-ALPN option.

6

Unfortunately, not in this case.