Renewal using certonly subcommand

[pcameron60]

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:

• The following errors were reported by the server:

  Domain: starlightproductions.ddnsfree.com
  Type: connection
  Detail: Fetching
  http://starlightproductions.ddnsfree.com/.well-known/acme-challenge/jMYPNVeVVMxD-HmN8qI0SIkwWPZdTyzf0hDBtMg_REw:
  Error getting validation data

  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.

Blockquote

[_az]

@pcameron60

because the target machine sits behind a router which has its own web server listening on port 80

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.

[schoen]

@_az

I get a “no route to host” error when trying to connect to your domain on port 80, but port 443 works fine.

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.

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

[schoen]

@schoen

By the way, this is often bad OS reporting of different ICMP errors, such as “administratively prohibited” (from firewalls).

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

Internet Control Message Protocol | Control messages

[_az]

@schoen

And that is the case here

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.

@pcameron60

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

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.

[pcameron60]

Unfortunately, not in this case.