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.
I ran this command:
certbot -v --work-dir $(pwd)/work --logs-dir $(pwd)/logs --config-dir $(pwd)/config renew --dns-godaddy-credentials credentials.ini
It produced this output:
Failed to renew certificate home.heisenbug.com with error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate (_ssl.c:1002)')))
The operating system my web server runs on is (include version):
Fedora 37
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.6.0
With that out of the way, the issue doesn't appear to have anything to do with any of the above. Seems to be an issue with the certificate for acme-v02.api.letsencrypt.org wrt python requests:
$ python -c 'import requests; print(requests.get(url = 'https://acme-v02.api.letsencrypt.org/directory\').text)'
...snip...
requests.exceptions.SSLError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate (_ssl.c:1002)')))
This is the same error I'm getting from certbot, so I'm assuming this is the cause. certifi is as up to date as I can make it:
Can you connect to https://acme-v02.api.letsencrypt.org/directory using other software on that system, such as curl? How about https://valid-isrgrootx1.letsencrypt.org?
Or maybe even openssl s_client -connect acme-v02.api.letsencrypt.org:443 and see what certificate chain you see?
Is there any chance of some "helpful" firewall intercepting the connection and presenting a fake certificate?
I have installed snap, but the distributed version doesn't have the godaddy credentials plugin I use installed. Is there any way to install a plugin in a snap, or do I need to resolve the issues in my pip-installed version?
No, the python requests module does not use the default system certificate root store. It's very annoying. However, this is the case for all deployments. I was kinda hoping that by posting here somebody would have hit this before. For example, if the snap works then it must have a solution for this.