Unable to force standalone plugin to use a spefic port



I ask certbot to challenge using standalone plugin and using http on port 10000; the standalone server is listening to port 1000, but acme challenge is done against port 80.

The command I am running

sudo certbot certonly --standalone --non-interactive  --preferred-challenge http-01 
   --http-01-port 10000 --agree-tos 
   --email realtebo@example.com --domains realtebo.example.com 
   --pre-hook 'sudo service webmin stop' 
   --post-hook 'sudo service webmin start' 
   --staging --dry-run

The error

 Domain: realtebo.example.com
 Type:   connection
 Detail: Fetching
 Timeout during connect (likely firewall problem)

Note about firewall

I am sure I have no firewall problem, Webmin is running on port 10000 and is reachable from outside

Seems it’s using the port 80

See the following portion of the log

  "validationRecord": [
      "url": "http://realtebo.example.com/.well-known/acme-challenge/nJANiwx4dXcJ5lnw-fVjdHyv7ZWop9GYf20pM7zl2ow",
      "hostname": "realtebo.example.com",
      "port": "80",
      "addressesResolved": [
      "addressUsed": "redacted"

I removed Ip but was correct.

It’s using port 80 ! Why?

standalone server is correctly using the port I specified

Note this portion of log (it is a port of the same run)

2018-08-29 13:56:28,854:INFO:certbot.auth_handler:Performing the following challenges:
2018-08-29 13:56:28,854:INFO:certbot.auth_handler:http-01 challenge for realtebo.example.com
2018-08-29 13:56:28,855:DEBUG:acme.standalone:Successfully bound to :10000 using IPv6
2018-08-29 13:56:28,855:DEBUG:acme.standalone:Certbot wasn't able to bind to :10000 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.

2018-08-29 13:56:42,465:DEBUG:certbot.plugins.standalone:Stopping server at :::10000...


Hi @realtebo

the ACME-protocol (and Letsencrypt) accepts only port 80 as start of the http-01 - validation.

Port 80 is one of the “official ports”. So if someone want’s to show that he has the right to manage the domain, port 80 is a good choice.

So you have to open port 80.

If I know it correct: http-01-port is only used if there is a second server in front of this machine (proxy or firewall). So that certbot connects port 80 of the proxy / firewall.


@JuergenAuer I think it might be to allow Certbot to bind the standalone HTTP-01 challenge server to a non-standard port such that another HTTP server already listening on :80 can be configured to redirect the challenge requests to the standalone server. Like you explained (thanks!) it won’t help @realtebo because the initial challenge request will always be directed to port 80 by design.


I can’t stop the other webserver that is occupying the port 80. I did manual DNS challenge and resolved

Port 80 is often overrequested. And sometime we came into a situation where absolutely cannot have it.

The problem of this in my situation is that I cannot automate this. I cannot keep a redirect live only for a thing to do once every two or three months. I think I am not the only having more than one webserver in the lan but not having a proxy or similar.

What if simply I cannot change company firewall rules and my service is on a different port and it’s exposed only on this port? This is not an uncommon choice.

DNS challenge cannot be automatically done because two run asks for different codes as txt record.

In this machine I have 3 different services. No one use the port 80. This because a different machine run a we on port 80 exposed. And we cannot stop it only for a renewal. And also if I can, I cannot automate stop of service from this machine to the other.

The big problem is not in production, but while developing a strategy for deploying and auto scaling, No, we do not reuse certificates and neither server names. We do not use wildcards because haproxy config will be absurdly complicated in handling them. No. This haproxy cannot listen port 80 and redirect to other machine so we can do a challenge every totally.

Doing complicated things like this is my work. Situation I inherited or I am forced to accept or implement.

This is only for sale of discussion. Not a request and not a polemic.

Anyqay, I kindly suggest to explain better the goal of this option.
And if one day could we have an option for change acme request port it should be great


The authorized ports are an industry standard. See section of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf and the definition of Authorized Port in 1.6.1.

That’s what DNS provider APIs are meant for. Certbot currently has support for several of them (although it depends on how you install Certbot), and other clients have support for others. You can allow Certbot to create the requested TXT records automatically, which will allow for automated renewal. If your DNS provider isn’t supported, you can use a CNAME record to refer the TXT lookup to a different zone on a different provider with a supported API (the CA’s TXT record lookup process will follow CNAME referrals), or use a different Let’s Encrypt client with different DNS provider API support.

One thing that we ought to do is more strongly discourage people from using --manual and mention that they should be using a DNS provider API instead.

That would be a useful idea; do you have a suggestion of where we should do so? Did you look at the Certbot documentation on the web or the --help text for this option?


It probably should emphasize automatic renewal (including the cronjob) is only possible when the manual plugin is used with scripts to facilitate the token adding and removal. Albeit it isn’t that manual anymore at that moment :grimacing:


Thanks for the PDF. I didn’t know it was a fixed requirement for CA certifications .

Thanks for this tool. There are of course a lot of different way to exit from situations like mine.

I was sure it was not a bug but I didn’t understand why it behaves in this way

So. I am fully satisfied.


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