Certbot 2.7.2 / error for CAA

Help
1

My CAA entries are (desec.io / domain is example.dedyn.io):

CAA 128 issuewild "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/11111111111"

and tried also with

CAA 128 issuewild "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/11111111111"

but working is only

CAA 128 issuewild "letsencrypt.org;validationmethods=dns-01"

2023-10-24 19:23:48,736:DEBUG:certbot._internal.renewal:Traceback was:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/renewal.py", line 537, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/main.py", line 1550, in renew_cert
renewed_lineage = _get_and_save_cert(le_client, config, lineage=lineage)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/main.py", line 131, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/renewal.py", line 396, in renew_cert
new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/client.py", line 428, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/client.py", line 496, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2023-10-24 19:23:48,744:DEBUG:certbot._internal.display.obj:Notifying user:

2023-10-24 19:23:48,745:ERROR:certbot._internal.renewal:All simulated renewals failed. The following certificates could not be renewed:
2023-10-24 19:23:48,746:ERROR:certbot._internal.renewal: /etc/letsencrypt/live/example.dedyn.io/fullchain.pem (failure)
2023-10-24 19:23:48,747:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2023-10-24 19:23:48,749:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/usr/local/bin/certbot", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.9/dist-packages/certbot/main.py", line 19, in main
return internal_main.main(cli_args)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/main.py", line 1873, in main
return config.func(config, plugins)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/main.py", line 1642, in renew
renewed_domains, failed_domains = renewal.handle_renewal_request(config)
File "/usr/local/lib/python3.9/dist-packages/certbot/_internal/renewal.py", line 565, in handle_renewal_request
raise errors.Error(
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
2023-10-24 19:23:48,753:ERROR:certbot._internal.log:1 renew failure(s), 0 parse failure(s)

Any hint here?

2

Not without the actual error message from the ACME server.

And I'm preeeeetty sure your subdomain isn't example. Note that providing the actual hostname is mandatory, as mentioned in the questionnaire:

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:

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.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2 Likes
3

seems pretty much that:

{
1070 "identifier": {
1071 "type": "dns",
1072 "value": "example.dedyn.io"
1073 },
1074 "status": "invalid",
1075 "expires": "2023-10-31T15:17:15Z",
1076 "challenges": [
1077 {
1078 "type": "dns-01",
1079 "status": "invalid",
1080 "error": {
1081 "type": "urn:ietf:params:acme:error:caa",
1082 "detail": "CAA record for example.dedyn.io prevents issuance",
1083 "status": 403
1084 },
1085 "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/90333833904/IllmaA",
1086 "token": "8Ky0mcFttrB0_HyNvsdfsdfdsfBhTlqp618mG05_qeJXK6PI",
1087 "validationRecord": [
1088 {
1089 "hostname": "example.dedyn.io"
1090 }
1091 ],
1092 "validated": "2023-10-24T15:18:38Z"
1093 }
1094 ],
1095 "wildcard": true

1082 "detail": "CAA record for example.dedyn.io prevents issuance"

does it point to be on the dedyn.io - side rather than letsencrypt?

4

dedyn.io doesn't have a CAA RR set up, so that's not it.

Without knowing the actual hostname, we can only guess.

2 Likes
5

Just one: If there is any CNAMEing, then you may also need to check the other domains' CAA settings.

2 Likes
6

its only for *.example.dedyn.io and example.dedyn.io, so an "issuewild"

1 Like
7

I don't see a CAA record for example.dedyn.io. But assuming that you're actually trying to issue for some other name, and you're trying to issue for both the name itself as well as a wildcard *. before it, then you would need a CAA that has both issue (for the bare name) and issuewild (for the wildcard), or a CAA that has only issue (which would mean for both). Having just issuewild I don't think would allow for issuing the non-wildcard name of the cert.

(Edited to cross out my unsubstantiated nonsense.)

5 Likes
8

If there's an issuewild CAA record, then any CA can issue for non-wildcard certs.

The RFC says:

Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name.

(And I confirmed this works with a domain of mine)

4 Likes
9

Yeah, I guess I should have looked at the actual spec before making wild unsubstantiated guesses. Hmm. I guess we'd need to see the actual names being requested and the actual CAA record in order to figure out what's going on.

Maybe a proof that the fastest way to get a correct answer on the Internet is to post an incorrect answer first. :wink:

4 Likes
10

I checked through Let's Encrypt logs for CAA failures under dedyn.io to see if I can tell what's wrong.

You've put an issuewild with an accounturi that's a production account, but you're testing in staging with a different account URI.

If not, you'll need to share your domain, account IDs, and exact CAA records for further help.

7 Likes
11

my working setup is

grafik
grafik798×236 10.6 KB

dig:

;; ANSWER SECTION:
example.dedyn.io. 30 IN CAA 128 issuewild "letsencrypt.org;validationmethods=dns-01"

certbot --dry-run showing no issues

whereas

CAA 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/11111111111"
showing up correcty with dig but certbot gives the mentioned errors

1 Like
12

The —dry-run certbot command uses staging, which will have a different account, which is why your CAA record blocks it.

6 Likes
13

seems my cert is due beginning of Nov, either I wait or for validation purpose I can use the prod environment.

1 Like
14

solved - a foreced renew on PROD environment works, seems the issue was the stage system

1 Like
15

Is there a way to add more than one accounturi in CAA?

2 Likes
16

Yes, you just have two CAA entries, both for letsencrypt.org but with different parameters.

0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/0000000"
0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/99999999"
0 iodef "mailto:whatever@example.test"

I do this on my personal domains.

5 Likes
17

upgraded to certbot 2.7.4 meanwhile, now getting for
certbot -v --force-renewal --authenticator dns-desec --dns-desec-credentials /etc/letsencrypt/.secrets/miharu.dedyn.io.ini

2023-11-03 12:02:01,189:DEBUG:certbot._internal.main:certbot version: 2.7.4
2023-11-03 12:02:01,191:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/local/bin/certbot
2023-11-03 12:02:01,191:DEBUG:certbot._internal.main:Arguments: ['-v', '--force-renewal', '--authenticator', 'dns-desec', '--dns-desec-credentials', '/etc/letsencrypt/.secrets/miharu.dedyn.io.ini']
2023-11-03 12:02:01,193:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#dns-desec,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2023-11-03 12:02:01,299:DEBUG:certbot._internal.log:Root logging level set at 20
2023-11-03 12:02:01,307:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-desec and installer None
2023-11-03 12:02:01,309:DEBUG:certbot._internal.plugins.selection:No candidate plugin
2023-11-03 12:02:01,310:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * dns-desec
Description: Obtain certificates using a DNS TXT record (if you are using deSEC.io for DNS).
Interfaces: Authenticator, Plugin
Entry point: EntryPoint(name='dns-desec', value='certbot_dns_desec.dns_desec:Authenticator', group='certbot.plugins')
Initialized: <certbot_dns_desec.dns_desec.Authenticator object at 0x736a6b50>
Prep: True

Whats wrong?

18

Why are you using --force-renewal?
Can't you just test with --dry-run?

2 Likes
19

I do have CAA, so not working on stage

certbot --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.

not used to get that

20

Please show the renewal config file.

2 Likes