How do I specify a port other than 80 when adding SSL certificate using Certbot?

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?

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.