AutoSSL CAA Failture with accountURI

Help
1

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

Current Provider: Let’s Encrypt™

Provider Account ID: 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), 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

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):

2

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?

3

Here https://unboundtest.com/m/CAA/spicertransmission.com/GRV4SBZK is showing a CAA record of

;; ANSWER SECTION:
spicertransmission.com.	0	IN	CAA	0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/2355938557"
5

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!

6

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.

7

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.

8

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.

9

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

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
And

;; 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.

10

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).

11

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 :slight_smile:

12

Ah, thanks for that.

Now you know from Peter's explanation that issuewild only controls wildcard cert issuance so not surprising it worked for non-wildcard cert.

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?

13

@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

14

Screen Shot 2025-04-22 at 7.58.40 PM
Screen Shot 2025-04-22 at 7.58.40 PM1508×1262 229 KB

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 and perhaps the www variation.

15

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.

16

Any chance that your Let’s Encrypt account ID being used by the ACME Client is not 2355938557?

17

Very possible! The AutoSSL logs are super lackluster, so it's hard to tell what is being used :frowning: 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 :wink:

18

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 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 state
"For example, if ca1.example.net has requested that its customer 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 CAA 0 issue "ca1.example.net; account=230123"

The semantics of parameters to the issue Property Tag are determined by the Issuer alone."

19

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.