18

I have a server which runs 2 different web servers (Apache and Nginx). The Apache server takes care of all the traffic directed to Wordpress sites whereas the Nginx server serves my Python API and React Web App.

Due to conflicting ports with Apache, I had to set up the API to run on port 88 and the React app to run on 90. I tested it this way and it worked. All the requests will be forwarded to 443 so I thought it doesnt matter what the unsecure port is.

When I finally ran the command to add the certificate:

sudo certbot --nginx -d a.domain.com 

which gave me an error. Upon further examination, I found out that it was trying to open the domain on port 80 instead of 88. I did some research and found the --http-01-port rule and set it to 88 but it gave me the same error again:

sudo certbot --nginx --http-01-port 88 -d a.domain.com 

After trying so many times, I am afraid that certbot might soon block me for a few hours or days due to suspicions of spam and I am running out of possible solutions.

Has anyone dealt with this before? How'd you solve this?

1
  • 3
    I recommend using reverse proxy setup on port 80, which then forwards requests to different web servers. Commented Nov 20, 2021 at 21:37

4 Answers 4

20

There is no way to specify a different port than defaults (80/443).

I recommend you to use the acme-dns validation. I use it and it works fine. More details here : https://www.digitalocean.com/community/tutorials/how-to-acquire-a-let-s-encrypt-certificate-using-dns-validation-with-acme-dns-certbot-on-ubuntu-18-04

Equally acme-dns is very useful to issue Let's Encrypt certificates for an intranet with public domain.

5

The suggestion of @tero-kilkanen bring me to the idea to use the default-catch all VHost on port 80 for verifications, and give its webroot to the certbot command for any domain:

certbot certonly --webroot -w /var/www -d www.example.com 

Of course this only works, if the default catch-all VHost has a webroot. But if not, it's still possible to use rewrite rules to perform a relocation (f.e.) if the peer isn't a certbot, and to route to an internal VHost which has a webroot for certbot validation requests (which you can identify by looking for the .well-known path, f.e. - see https://eff-certbot.readthedocs.io/en/stable/using.html#webroot). For certificate updates you will have to rewrite the final VHost to locate to the default catch-all VHost.

It'd be nice to get around that verification at all, if the target domains A record already points to the requesting server IP address (which is a kind of DNS verification already). Stopping/starting a webserver only for the purpose of creating/updating a ceritificate, where a reload would be enough, is just too much and hard to accept. But maybe I just don't see the possibly good reason why they did it like this.

1

certbot certonly --standalone -d myapp.domainexample.com --non-interactive --agree-tos --email [email protected] --http-01-port=9090

1
  • 8
    According to the man entry, it should be ignored by conforming ACME servers. --http-01-port HTTP01_PORT Port used in the http-01 challenge. This only affects the port Certbot listens on. A conforming ACME server will still attempt to connect on port 80. (default: 80) Commented Jul 18, 2022 at 14:21
-1

When using standalone, you can use --http-01-port and --http-01-address to specify the port that it will listen on for the challenge. The server will still connect to port 80, so you need to ensure that the port gets to the standalone listener on the other port.

The renewal config equivalent settings: (set for 127.0.0.1:8000)

[renewalparams] http01_address = 127.0.0.1 http01_port = 8000 

In my case port 80 is in use by sniproxy, so I configured that to forward traffic for the cert hostname to 127.0.0.1:8000.

(In the questioner's case, Apache would need to forward the traffic to the certbot) (and standalone would need to be used instead of the --apache or --nginx parameters (for all certificates))

For some web servers on port 80 the configs would look like this (if still serving other things) (a simple port forward would work if that is not needed)

Apache:

<Location "/balancer-manager"> ProxyPass "/.well-known/acme-challenge" http://127.0.0.1:8000 </Location> 

nginx:

location /.well-known/acme-challenge/ { proxy_pass http://127.0.0.1:8080; } 

If port 80 is not in use (e.g. for a certificate for a mail server), using --standalone without extra settings is by far the easiest option. (Certbot will listen on port 80, instead of relying on a web server for that)

5
  • This does not help the OP. Commented Apr 8 at 11:29
  • @GeraldSchneider But a question for my problem would be marked a duplicate of this - how do I get certbot to listen on a port other than 80.... (and the OP can set het server on port 80 to proxy, which the answer does cover) (last paragraph) Commented Apr 8 at 12:36
  • @GertvandenBerg The issue with that is that proxies tend to require a lot of re-configuration on a lot of in-place configs. The approved answer is currently the best way to handle this scenario and is on-topic with the question. Commented Apr 9 at 14:07
  • @Dimitar: You add a fixed forward to port e.g. 8000 for /.well-known/acme-challenge and run all the certbot standalone validators on there... If the validator is not running, the URLs returns a 504. DNS validation needs DNS credentials floating around, which is a huge risk, at least if the can't be limited, like for Cloudflare. (In nginx and Apache it is a ~3 line block) Commented Apr 10 at 8:04
  • And in the actual question, since 80 does not seem to be in use, just using standalone makes more sense, but that doen't answers the question in the title, since it doesn't specify a port other than 80. (but neither does the accepted answer - it answers a different question - how to avoid HTTP-01 validation) Commented Apr 10 at 8:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.