I successfully issued a certificate on January, on Ubuntu 20.04 + nginx, I have ssh root access.
The provider is ovh, the certificate is not wildcard.
Following certbot instructions it did all automatically and back then "sudo certbot renew --dry-run" worked.
certbot version 1.13.0
Now the renewal returns:
Failed to renew certificate mydomain.com with error: Error determining zone identifier for mydomain.com: 403 Client Error: Forbidden for url: https:/
/eu.api.ovh.com/1.0/domain/zone/. (Are your Application Key and Consumer Key values correct?)
cat /etc/letsencrypt/renewal/mydomain.com.conf
# renew_before_expiry = 30 days
version = 1.11.0
archive_dir = /etc/letsencrypt/archive/mydomain.com
cert = /etc/letsencrypt/live/mydomain.com/cert.pem
privkey = /etc/letsencrypt/live/mydomain.com/privkey.pem
chain = /etc/letsencrypt/live/mydomain.com/chain.pem
fullchain = /etc/letsencrypt/live/mydomain.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = 852[...]
authenticator = dns-ovh
installer = nginx
dns_ovh_credentials = /root/ssl/ovh.ini
manual_public_ip_logging_ok = None
server = https://acme-v02.api.letsencrypt.org/directory
Why this error occurs? How can I test if my credentials are still valid? Could it be related to the recent OVH incident?
OVH had an entire datacenter in Strasbourg burn down recently.
It's conceivable that their DNS API availability was affected somehow—@xalloc, I know OVH support is probably extraordinarily busy, but would it be possible to check with them whether this could be the case?
The current status as reported by the Let's Encrypt status page is Service Disruption as at 2021-03-24 17:02:51.975 +0000 UTC. Depending on the reported problem, this may affect certificate issuance. For more information, please visit the status page.
Not really, only a test certificate log has a disruption. See the https://letsencrypt.status.io/ link for more info. This shouldn't affect certificate issuance.
Are you still getting the exact same error as before?
It's really hard to say anything about it.. If I look at the code for the OVH DNS plugin, the error is triggered by the "403 Client Error" string returned by OVH when accessing an URL from the API, which is also presented in the error message.
Without more info presented by us by the plugin, it's really hard to pin down where the actual issue is.
Can you perhaps experiment with the OVH API on the staging server? Trying to get a certificate from a testing subdomain with --staging as an option to certbot and see if you can issue certificates with the OVH DNS authenticator?
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Cert is due for renewal, auto-renewing...
Simulating renewal of an existing certificate for domain.com and www.domain.com
Performing the following challenges:
http-01 challenge for domain.com
http-01 challenge for www.domain.com
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
The dry run was successful.
The command is to create a new cert, but the output says it simulates renewal anyway?
Due to the certificate expiring next week, I'll try to issue a new cert from scratch. Can I use that command to do that?
Because it contains the same hostnames as an already existing certificate.
But if I understand correctly: you don't actually NEED the OVH DNS plugin? In that case you can just remove the --dry-run from the command you just ran and get a real certificate....
All this time I assumed you actually required the dns-01 challenge.. Most people don't take the effort to get a DNS plugin up and running when it's 1000x easier to just run the http-01 challenge, as you did just now.
A perfect example that due to obscurity by OP we don't get to see the real domain name in question, so we can't check further than the limited information offered..
I see now the two commands used two different challenges, but forgive me if I don't understand. How can I renew without using the ovh plugin?
I don't even know why it was installed.
A perfect example that due to obscurity by OP we don't get to see the real domain name in question, so we can't check further than the limited information offered..
Sorry about that, that's because it's for a third-party website and I don't know if I can write about it without third-party consent.
EDIT: Ok i see after the successful http-01 renewal, the renew command uses the same challenge. Thanks a lot for your support!
Because DNS isn't the only way Let's Encrypt can validate ownership of the hostname(s). Please see the following documentation:
Great! Indeed, certbot stores the most recently used command line options in the renewal configuration file, so it'll use the --nginx option you've used. Note that --dry-run doesn't store this info, as it's for testing only. But once you've issued a real, valid certificate with the new options, it gets stored for future use.
