I have previously successfully generated certificates the exact same way I am trying to renew, and now generate them again, but I receive the errors state below.
I have even elevated the related service-account’s rights to owner, with no avail.
I am in big sh*t currently because of this, I would really appreciate any insight that may rescue me out of this predicament.
I ran this command: sudo docker run -it --name certbot --rm -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" -v "/home/$(whoami)/.secrets/certbot:/secrets" -v /var/log/letsencrypt:/var/log/letsencrypt certbot/dns-google --dns-google --dns-google-credentials /secrets/google.json --server https://acme-v02.api.letsencrypt.org/directory certonly --staging --break-my-certs -d '*.apps.cf.smart-iiot.io' -d '*.sys.cf.smart-iiot.io' -d '*.ws.cf.smart-iiot.io' -d '*.cf.smart-iiot.io' -d '*.login.sys.cf.smart-iiot.io' -d '*.uaa.sys.cf.smart-iiot.io'
It produced this output:
Failed authorization procedure. uaa.sys.cf.smart-iiot.io (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.uaa.sys.cf.smart-iiot.io, sys.cf.smart-iiot.io (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.sys.cf.smart-iiot.io, login.sys.cf.smart-iiot.io (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.login.sys.cf.smart-iiot.io
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: uaa.sys.cf.smart-iiot.io
Type: unauthorized
Detail: No TXT record found at
_acme-challenge.uaa.sys.cf.smart-iiot.io
Domain: sys.cf.smart-iiot.io
Type: unauthorized
Detail: No TXT record found at _acme-challenge.sys.cf.smart-iiot.io
Domain: login.sys.cf.smart-iiot.io
Type: unauthorized
Detail: No TXT record found at
_acme-challenge.login.sys.cf.smart-iiot.io
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
My web server is (include version):
Not applicable
The operating system my web server runs on is (include version):
Cloud Foundry
My hosting provider, if applicable, is:
Google Cloud
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No
As per Cloud DNS claimed, you might need to wait a few seconds before asking certbot to check the DNS records since GCP need time to process your change (request).
Do you mind to try asking it to check after 360 seconds (by adding the below argument)? --dns-google-propagation-seconds 360
Yes, certbot is complaining:
Unsafe permissions on credentials configuration file: /secrets/google.json
I have also changed the path of where the credentials file was and tested. I have also generated a new service account, changed the credentials file and tested. It resulted in the same error.
So if you check your Cloud DNS dashboard for that domain is your TXT record being set at all? For google DNS I have seen it take an hour for all the nameservers to be reporting the correct response (3600 seconds).
I have noticed that it generates TXT records just for the first 3 entries. It is the remaining 3 entries that are generating the errors. I can’t see any difference between the first 3 and the last 3 wildcard dns entries.
Cerbot will not generate _acme-challenge TXT records for the following wildcards:
*.login.sys.cf.smart-iiot.io
*.sys.cf.smart-iiot.io
*.uaa.sys.cf.smart-iiot.io
Certbot will though generate _achme-challenge TXT records for the following wildcards:
*.apps.cf.smart-iiot.io
*.cf.smart-iiot.io
*.ws.cf.smart-iiot.io
Do you have another machine that are on GCP or have gcloud installed?
You could set a long enough interval and login to the other machine, check if certbot has set the records inside GCP (sometimes it’s just pending effective)
I haven’t worked on the Google plugin, but could you post the associated log from /var/log/letsencrypt in the hope that we can see what Certbot and the plugin are trying to do here?
I think I know what the problem is. Any URL with a sub-domain sys generates an error. If I change *.sys.cf.smart-iiot.io to *.ttt.cf.smart-iiot.io then it will work simular to: *.login.sys.cf.smart-iiot.io *.uaa.sys.cf.smart-iiot.io. If I change them to *.login.ttt.cf.smart-iiot.io *.uaa.ttt.cf.smart-iiot.io, then it will work.