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.
What does this show? Please post the output in a response
certbot certificates
I see you got certs for this domain in the past. But, the most recent expired more than a month ago. This command will tell us what your system knows about these older certs.
@agentx You can see in the Certbot documentation that there are different plugins for Certbot which use different methods to satisfy the certificate authority's challenge. Each of --nginx, --standalone, and --webroot (or equivalently choosing an option from the authentication plugin selection menu) uses a very different approach to do this.
Each one could be appropriate in a different situation, depending on how your web server is set up.
Separately,
This suggests that the automated renewals are already working (using whatever option was used when you first obtained the certificate), or else not yet due. Unless you've changed something since then that you expect might cause the renewals to fail, it's still possible that they're working correctly. certbot renew without --force-renewal only attempts to renew certificates that are "due" based on having under 30 days of remaining validity, which is in accordance with Let's Encrypt's recommendations.
And to be absolutely clear: there usually is absolutely no point in using --force-renewal. And it also does not magically make a failing challenge succeed, what is something some users think.
The 404 error when using the --nginx option usually means something is wrong in your nginx config. Please upload the certbot log file. Make a copy of it to a .txt file and use the upload button in the post menu.
The log will show us the temp changes by Certbot and why they are not working
