I'm working on the automation to issue SSL certificates using certbot, with a delegated domain, in GCP Cloud DNS, for the dns-01 validation.
Unfortunately the gcp module doesn't support domain delegation so I have to do it with --manual. Also I'm using google's server (https://dv.acme-v02.api.pki.goog/directory)
The initial certificate issuing works fine, but when I run the renewal (certbot renew --dry-run) it fails with the following error:
Challenge failed for domain dummy.researchgate.net
dns-01 challenge for dummy.researchgate.net
Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: dummy.researchgate.net
Type: caa
Detail: During secondary validation: While processing CAA for dummy.researchgate.net: CAA record for researchgate.net prevents issuance
The renewal conf file contains the server correct google acme server, but it seems it's not using it, as it's complaining that is missing the CAA entry.
archive_dir = /etc/letsencrypt/archive/dummy.researchgate.net
cert = /etc/letsencrypt/live/dummy.researchgate.net/cert.pem
privkey = /etc/letsencrypt/live/dummy.researchgate.net/privkey.pem
chain = /etc/letsencrypt/live/dummy.researchgate.net/chain.pem
fullchain = /etc/letsencrypt/live/dummy.researchgate.net/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = XXXXXXXXXXXXXXX
pref_challs = dns-01,
server = https://dv.acme-v02.api.pki.goog/directory
authenticator = manual
manual_auth_hook = /root/gcp-validate.sh
manual_cleanup_hook = /root/gcp-cleanup.sh
key_type = ecdsa
Did you see a similar issue, or was anyone able to renew your certificate using pki.goog, using gcp's cloud dns delegated domain?
Not sure if Google even has a staging environment to "dry run" on.. So you might be limited with that respect.
Ideally, Certbot would be able to somehow know the appropriate staging environment from a configured server variable.. Maybe CAs could add that to the meta object of their ACME endpoint directory? Then ACME clients could query the ACME server directory, see if there's a "staging" entry in the "meta" object and only if not present use a hardcoded fallback..
It does: https://dv.acme-v02.test-api.pki.goog/directory
Note this needs its own EAB secret when setting up the ACME account.
Some care is required when using "test" servers without --dry-run as they may overlay previous production certs.
Not sure if --dry-run --server https://dv.acme-v02.test-api.pki.goog/directory works anymore as Certbot recently changed some things related to that. I just haven't tested that recently.
One safe option is to use --cert-name TestCert along with the alternate test --server value to ensure you don't clobber a production cert
There has been discussion about how to handle things that arose after they implemented ARI. There were early bugs with them checking the wrong server especially with --dry-run. There were various discussions about whether to ignore the server in the config vs command line and related issues. I don't know where they landed on those several discussions.
Pretty sure @petercooperjr and I tested that --server did set the named server but only if --server appeared after --dry-run. But, that was some time ago.
Just ran the --dry-run with the --server after and it worked!
had to use the non-test endpoint, as it requires registration (which my server is only registered with the main one only) but the dry-run validation was successful
