Certificate issuance failure due to rechecking caa error

Certificate issuance for a Multi-domain certificate with order url is failing with the below error during finalization.

Error finalizing order :: rechecking caa: During secondary validation: Secondary validation RPC

However, the above error response message does not include domain information for which it failed. Is it possible to get the details for which the CAA error occurred?

1 Like

The "Secondary validation RPC" part suggests, to me at least, that this was some kind of internal error within the Let's Encrypt validation structure. You see, those secondary validation locations need to communicate with the main validation server and vica versa and I believe they're using this "RPC" stuff.

I recon this was just a temporary hickup and it shouldn't bother you again.

Also, from the order URL you've provided, it seems the order is currently "ready":

"status": "ready"

Which, according to the RFC means:

Once all of the authorizations listed in the order object are in the "valid" state, the order transitions to the "ready" state.

your order should be good to go to issue a certificate as apparently all authz are now valid and your ACME client should be able to finalize the order.

1 Like

Though the order is in a ready state, the finalization is failing with the above error.
Can you please guide me to get the URL for downloading the certificate for such cases?

that url is now 404s as LE trimed failed order: what was in it?

1 Like

What's your domain? To diagnose this you'd need to check all the DNS nameserver responses for CAA records. Sometimes this happens when a DNS nameserver server is blocking responses or it just needs a reboot.

Check your CAA record response with https://unboundtest.com/

Check your general DNS health with https://unboundtest.com/

1 Like

This is the latest order url, which failed to finalize the order because of the above error without domain information. Is it possible to get the domain details for which the CAA error occurred?

No I don't believe so, I would suggest having less domains included on a single certificate would be less likely to result in an error like this (which seems to result from an internal last-minute check process).

[Edit:

The problem with having many different domains in one cert is that you have an upper limit of 100 names, but you can also suffer renewal failures if one domain is misconfigured or has temperamental DNS nameservers.

To work around this problem you could try a different CA such as Google Trust Services, but the real scalable and fault tolerant solution is to have one cert per domain.]

3 Likes

I noticed all those domains are pointed to same nameserver, it may be a lot of dns request from same IP triggered zoho's rate limit and errored out?

2 Likes