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?

Dimitar
  • 192
  • 1
  • 1
  • 11

4 Answers4

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.

4

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.

nd_
  • 41
1

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

-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)