# AutoSSL CAA Failture with accountURI **URL:** \ **Category:** Help\ **Created:** [April 22, 2025, 4:38pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597 "2025-04-22T16:38:17Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 22, 2025, 4:38pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/1 "2025-04-22T16:38:17Z")
We are experiencing a strange issue where, when including the accountURI within our CAA record, AutoSSL via cPanel, with Let's Encrypt as the provider, fails to issue certificates, citing that it is forbidden via the CAA. We have confirmed that the listed Provider ID in cPanel matches the accountURI listed in the CAA record itself. We have rebooted the server, as well as waited 24+ hours in the event any old DNS records have been cached on Let's Encrypt's end, but we are still experiencing the same issue. [https://unboundtest.com/m/CAA/spicertransmission.com/GYXHYUXC](https://unboundtest.com/m/CAA/spicertransmission.com/GYXHYUXC) **Current Provider:** Let’s Encrypt™ **Provider Account ID:** [https://acme-v02.api.letsencrypt.org/acme/acct/2355938557](https://acme-v02.api.letsencrypt.org/acme/acct/2355938557) We have reached out to our server provider, but they seem stumped, and are recommending simply removing the accountURI from the CAA record. This seems to work properly based on our initial testing with an alternate domain, but our IT team would like to require the accountURI for security hardening purposes, so we are hoping to find a solution here that will allow us to continue to include it while also using Let's Encrypt for SSL certificates. 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](https://crt.sh/?q=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: [spicertransmission.com](http://spicertransmission.com) I ran this command: AutoSSL via cPanel It produced this output: DNS CAA records forbid "Let's Encrypt" from issuing certificates My web server is (include version): The operating system my web server runs on is (include version): AlmaLinux v8.10.0 STANDARD virtuozzo My hosting provider, if applicable, is: KnownHost 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): Yes, cPanel 126.0.14 The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 22, 2025, 4:59pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/2 "2025-04-22T16:59:34Z")
Welcome to the community @kferencz I am not expert at AutoSSL but a common issue that occurs with accounturi CAA is that a Let's Encrypt Staging account is different than a LE production account. You have your production account listed. Are you by chance getting a CAA reject when trying the Staging system? ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [April 22, 2025, 5:01pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/3 "2025-04-22T17:01:42Z")
Here [https://unboundtest.com/m/CAA/spicertransmission.com/GRV4SBZK](https://unboundtest.com/m/CAA/spicertransmission.com/GRV4SBZK) is showing a CAA record of ```nohighlight ;; ANSWER SECTION: spicertransmission.com. 0 IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/2355938557" ``` ---
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 22, 2025, 5:48pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/5 "2025-04-22T17:48:11Z")
Are you noting an issue with this record, or just sharing via text for reference? It seems to match what we'd expect using the accountURI / Provider ID, but we can adjust if there's something misconfigured! ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [April 22, 2025, 5:51pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/6 "2025-04-22T17:51:58Z")
I ran into an issue with a CA (not Let's Encrypt, didn't try AutoSSL), that I cannot remember witch one, that wasn't happy with CAA having much other than their identifier in the CAA. Yet I know there are DNS Provider who populate the CAA with several CAs; so maybe my observation was just a glitch. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [April 22, 2025, 5:54pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/7 "2025-04-22T17:54:08Z")
That record looks good to me, assuming that it's only production that's issuing certificates for it, and that it's the account id that your client is sending. I think in order to dig into it more you'd need to include some logs or the like from an attempt that's failing, to see what account it's using, what ACME server it's using, and what the exact error message it's getting back is. ---
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 22, 2025, 7:38pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/8 "2025-04-22T19:38:45Z")
A strange update - if we revise the CAA record from "issue" to "issuewild", the certificate seems to issue properly. Any insight as to why that might happen? I was under the impression that the "issue" directive covered specific and wildcard instances, whereas "issuewild" was simply for providing alternate instructions for a wildcard certificate. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 22, 2025, 7:57pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/9 "2025-04-22T19:57:45Z")
Are you talking about `spicertransmission.com` or `spicerparts.com` ? Because transmission has the same CAA record as before. Did you try issuewild and then change it back? See: [https://unboundtest.com/m/CAA/spicertransmission.com/5KO35XEW](https://unboundtest.com/m/CAA/spicertransmission.com/5KO35XEW) A cert check for transmission returns a cert for the domain `spicerparts.com` issued by DigiCert. Its CAA record allows just DigiCert (not Let's Encrypt). See: [SSL Checker](https://decoder.link/sslchecker/spicertransmission.com/443) And ```nohighlight ;; ANSWER SECTION: spicerparts.com. 0 IN CAA 0 issue "digicert.com" ``` We really need to see the detail logs of the cert request that AutoSSL is making. This is far more likely some kind of AutoSSL config problem rather than a Let's Encrypt problem with CAA in general. I don't see a cert for `spicertransmission.com` issued by anyone in the last 7 days. Sometimes there are lags posting to the CT logs but Censys (which I used) is usually pretty quick. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [April 22, 2025, 8:18pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/10 "2025-04-22T20:18:52Z")
> [@kferencz](#): > > I was under the impression that the "issue" directive covered specific and wildcard instances, whereas "issuewild" was simply for providing alternate instructions for a wildcard certificate. Yes, though if there are _only_ issuewild directives and no issue directives, then there are no constraints on issuing a non-wildcard name (much like if there were no CAA record at all). ---
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 22, 2025, 8:48pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/11 "2025-04-22T20:48:36Z")
Apologies - I should have been more clear. We tried an alternate, parked domain on a separate server by the same provider to try to determine if the issue was domain, server or cPanel / AutoSSL specific. We entered a similar CAA restriction on that domain, and ran into the same roadblock. Updated the CAA to "issuewild" and it worked fine. Removed the CAA entirely, same situation (obviously) - certificate issued just fine for this test domain. Unfortunately, AutoSSL's logs are incredibly lackluster. They just note the failure without any further details, so debugging here is difficult. I had a conversation with cPanel (who powers AutoSSL), and they seemed to indicate they don't currently support the "accounturi" parameter in however they validate and issue certificates using Let's Encrypt. Hopefully that changes in the future. Appreciate everyone's assistance here in this thread 🙂 ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 22, 2025, 9:11pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/12 "2025-04-22T21:11:09Z")
Ah, thanks for that. > [@kferencz](#): > > Updated the CAA to "issuewild" and it worked fine. Now you know from Peter's explanation that issuewild only controls wildcard cert issuance so not surprising it worked for non-wildcard cert. > [@kferencz](#): > > I had a conversation with cPanel (who powers AutoSSL), and they seemed to indicate they don't currently support the "accounturi" parameter It really has nothing to do with the ACME Client (AutoSSL). The Let's Encrypt ACME Server is the one ensuring that the CAA accounturi value matches the account used by the ACME Client. Every cert request by any client must include its ACME Account so there is nothing that AutoSSL has to do to "support" that. That is an essential requirement for getting a cert and always has been. We want to see the logs mostly to verify the ACME Account used in the ACME API requests. It's unfortunate they don't have anything useful. But, we'd also like to see the exact error message. Sometimes subtle differences in the message are good clues. When you request the cert for `spicertransmission.com` what are all the domain names you are requesting on that cert? I ask because each level of the domain is checked for CAA records. Could you have a stray CAA on a subdomain(s) or even a different apex domain combined on the same cert? ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 22, 2025, 9:36pm UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/13 "2025-04-22T21:36:48Z")
@kferencz I see your post at the cPanel forum. Will be interesting to see what they say. My only guess is the account number you see displayed as the Provider isn't the account that is actually used to talk with Let's Encrypt's server. [https://support.cpanel.net/hc/en-us/community/posts/31589825342231-AutoSSL-CAA-with-accounturi-Support-Possible-Issue](https://support.cpanel.net/hc/en-us/community/posts/31589825342231-AutoSSL-CAA-with-accounturi-Support-Possible-Issue) ---
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 23, 2025, 12:05am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/14 "2025-04-23T00:05:52Z")
![Screen Shot 2025-04-22 at 7.58.40 PM](https://global.discourse-cdn.com/letsencrypt/original/3X/5/3/53baa38462ee161f36206911eb66207159ac1b8c.png) Here is the full log. Not super helpful, unfortunately. All of the additional subdomains are auto-generated via cPanel domain creation, so they can be ignored, unless their existence hinders the certificate generation in some way. At this point, we're simply trying to issue a certificate that covers [spicertransmission.com](http://spicertransmission.com) and perhaps the www variation. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 23, 2025, 12:25am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/15 "2025-04-23T00:25:31Z")
I think AutoSSL support may be right that they don't support it. Some ACME Clients do their own validation checks before submitting the cert request to Let's Encrypt. Those messages look like they came from something like that. That is, their own pre-check saw a CAA record with "stuff" in it that they didn't recognize and issued this error. The error from LE is considerably different. While AutoSSL may be modifying the LE message I think given what they've said and that we observe that it might be their fault to start with. ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [April 23, 2025, 12:26am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/16 "2025-04-23T00:26:16Z")
Any chance that your Let’s Encrypt account ID being used by the ACME Client is not `2355938557`? ---
**Author:** ![kferencz](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kferencz](https://community.letsencrypt.org/u/kferencz)\ **Post date:** [April 23, 2025, 12:37am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/17 "2025-04-23T00:37:55Z")
Very possible! The AutoSSL logs are _super_ lackluster, so it's hard to tell what is being used ☹ Trying to work with our server provider to see if we can get any more information, but the above account ID is what is currently set at the AutoSSL configuration level (both in the UI and AutoSSL's config file), so theoretically, it _should_ be using that provider ID...key word there being should 😉 ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [April 23, 2025, 12:43am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/18 "2025-04-23T00:43:58Z")
Is this portion, `accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/235593855`, really needed? As an experiment would you be willing to remove it (at least temporarily)? ### Edit Why I ask is from here [https://letsencrypt.org/docs/caa/#examples](https://letsencrypt.org/docs/caa/#examples) states " Finally, OtherCA can also issue certificates, but only if the request comes from account number `123456` , and **only if OtherCA recognizes and knows how to correctly handle the `accounturi` restriction**." I wonder if the AutoSS knows how to handle `accounturi`. And from here [https://datatracker.ietf.org/doc/html/rfc8659#section-4.2](https://datatracker.ietf.org/doc/html/rfc8659#section-4.2) state "For example, if [ca1.example.net](http://ca1.example.net) has requested that its customer [account.example.com](http://account.example.com) specify their account number "230123" in each of the customer's CAA records using the (CA-defined) "account" parameter, it would look like this: [account.example.com](http://account.example.com) CAA 0 issue "[ca1.example.net](http://ca1.example.net); account=230123" The semantics of parameters to the issue Property Tag are determined by the Issuer alone." ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [April 23, 2025, 5:40am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/19 "2025-04-23T05:40:09Z")
These logs don't look like any of the error messages that we would return. I suspect that AutoSSL is checking your CAA records itself before even attempting actual validation. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [May 23, 2025, 5:40am UTC](https://community.letsencrypt.org/t/autossl-caa-failture-with-accounturi/236597/20 "2025-05-23T05:40:41Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.