9

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
  • 2
    I recommend using reverse proxy setup on port 80, which then forwards requests to different web servers. Nov 20, 2021 at 21:37

3 Answers 3

14

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.

2

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
  • 6
    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)
    – Dylan
    Jul 18, 2022 at 14:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .