Error finalizing order :: Unable to meet CA SCT embedding requirement

Hi Folks,

This is a new one for me, a user of Certify The Web is repeatedly having trouble renewing their certs and the HTTP validation either times out waiting for LE to complete domain validation or it fails to finalize with Unable to meet CA SCT embedding requirement.

To my knowledge this is perhaps something to do with LE not being able to submit the cert to CT logs and it appears to only affect this one user. Failing to submit to CT logs wouldn't explain why http validation takes a long time to complete but assuming it eventually passes then presumably the two issues are not connected?

2025-05-28 15:18:42.514 -07:00 [INF] ---- Beginning Request [neilssilkscreen.com] ----

2025-05-28 15:18:42.514 -07:00 [INF] Certify/6.1.5.0 (Windows; Microsoft Windows NT 10.0.17763.0)

2025-05-28 15:18:42.514 -07:00 [INF] Beginning certificate request process: neilssilkscreen.com using ACME provider Anvil

2025-05-28 15:18:42.514 -07:00 [INF] The selected Certificate Authority is: Let's Encrypt

2025-05-28 15:18:42.514 -07:00 [INF] Requested identifiers to include on certificate: neilssilkscreen.com;www.neilssilkscreen.com

2025-05-28 15:18:43.947 -07:00 [INF] Created ACME Order: https://acme-v02.api.letsencrypt.org/acme/order/263893630/388709530197

2025-05-28 15:18:44.535 -07:00 [INF] Order is ready and valid. Auth challenges will not be re-attempted.

2025-05-28 15:18:44.536 -07:00 [INF] [Progress] Order authorizations already completed.

2025-05-28 15:18:44.536 -07:00 [INF] Resuming certificate request using CA: Let's Encrypt

2025-05-28 15:18:44.536 -07:00 [INF] [Progress] Requesting certificate via Certificate Authority

2025-05-28 15:19:20.419 -07:00 [ERR] Failed to finalize certificate order:  Error finalizing order :: Unable to meet CA SCT embedding requirements

2025-05-28 15:19:20.419 -07:00 [ERR] The certificate order failed to complete. Failed to finalize certificate order:  Error finalizing order :: Unable to meet CA SCT embedding requirements

Does anyone have any suggestions?

3 Likes

I've looked at our metrics and our overall rate of failing to get SCTs rounds to 0%, and when there are failures they're hitting timeouts. I'll check with others on the team if they have any ideas.

The only thing I can think of is that it's some sort of slowness between CAA rechecking and that's eating up time in a timeout somewhere.

That particular authz failed the ap-southeast-1 perspective - perhaps fixing whatever failed there might speed up things in a way that helps. If there's some geoblocking that could also explain the validation slowness.

5 Likes

Thanks, both authz in this order are marked valid, but can secondary validation fail from a perspective and the authz still passes overall?

I'm not seeing geoblocking in my own testing (including from Singapore), obviously users can be a little unsure of whether there is filtering in place or not, but from my testing it's not apparent.

I wouldn't rule out a CAA check problem but the reason I'm not yet pushing this back to the user is that it's reported as an internal server error at the ACME API. DNSViz is pretty unhappy about their DNS (UDP and DNSSEC) but I haven't dug into that yet because this error message was more unusual.

3 Likes

We allow 3/4 quorum to pass validation, but if we're waiting/hanging on that final region, that can eat up some time.

I agree that the UX here isn't ideal - we're hitting some internal timeouts, which suggests they're not quite set right. I mostly suggest the "figure out why CAA checking is slow/failing" as a potential immediately way to get some relief

6 Likes

Thanks, I'll raise the DNS issue with them, looks like UDP is blocked when DNSViz looks (but not for me).

3 Likes