Didn't it ask you what the weboot path was after you chose "2". The default for that is "ask" which means to prompt you.
If nginx is terminating HTTPS (and it likely is), you will need the cert in a server block for it.
If these two machines are on the same trusted network you may want to just use HTTP on your "backend" servers and not worry about that one having a cert from a public CA. The nginx front end handles the HTTPS (similar to how a CDN works).
You don't run that command in a cron job. You instead run the renew command. And, usually during install of Certbot itself there is one setup for you.
You didn't answer the other questions on the form you were shown so I can't give more specific advice than that. Please either answer the questions or refer to the Certbot docs
=================================
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Didn't it ask you what the weboot path was after you chose "2". The default for that is "ask" which means to prompt you.
No. I ran it several times, there was never a prompt.
If nginx is terminating HTTPS (and it likely is), you will need the cert in a server block for it.
Yes, HTTPS works and certbot manages those lines:
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
certbot certonly --webroot -w /path/to/webroot -d example.org
You don't run that command in a cron job. You instead run the renew command. And, usually during install of Certbot itself there is one setup for you.
I have to run that command (twice) because I have two domains and I need to specify the domain(s). "renew" only works on a default domain and doesn't allow the -d flag.
...
I'm back to my question: what webroot path do I include in commands if nginx is a reverse proxy server for a website on another VM?
No, that is not how "renew" works. When you get a certificate Certbot creates a renewal config file in /etc/letsencrypt/renewal. These are shown by sudo certbot certificates
The Certbot renew is normally run twice / day. It inspects each of your local certs and renews them when needed. ALL of the previously issued certs are inspected / renewed. The values (webroot, ...) used to get the cert initially are saved in this renewal config file and used again for the renew.
I have never seen that happen. Certbot doesn't guess at the webroot path. You can review its log to see what it did: /var/log/letsencrypt/letsencrypt.log
Were you reissuing that command for a domain that you already had a certificate for? Perhaps Certbot then used the webroot-path you provided earlier.
In any case, use the --webroot-path or just -w flag after --webroot and before any -d to set the webroot path. That path is where Certbot places the challenge token.
When Let's Encrypt sends you an HTTP request to verify you control that domain name your webserver must reply with the value from that file.
Usually you run Certbot on the same machine that handles that HTTP request. You can use file mapping of various kinds to reach a different machine. But, that other machine must be the one to reply to the HTTP challenge or the cert request will fail (as no other of your servers knows what that value is).
I think it would be helpful for you to explain what you are trying to achieve. I don't think you fully appreciate how certificates are best deployed or managed. We can help you with more info.
MikeMcQ thanks for all your comments, which made me realize my setup was very flawed. I purged everything certbot and ssl, reinstalled and used certbot --nginx and it set everything up right. I can't believe it was that simple.