I'm surprised to see 100 subproblems that are all identical. Does it mean that LE system tried to recheck the CAA for this domain 100 times before giving up? I ran this command: certbot certonly --webroot --staging --csr /var/cert_manager/certs/san132.csr -w /var/www/html -d ace.pusd.org -d admin.…

There do seem to be a couple of real problems in here: First, a simple one. A subproblem’s type should not include the urn:ietf:params:acme:error: prefix twice. Second, the duplicate sub-problems does seem like a bug. While Let’s Encrypt does look up the CAA records multiple times per authorizatio…

@_az , It seems you’ve determined this is a bug in your system and have steps to reproduce. is it really a bug on your end or have changes on your side simply revealed a misuse on our end? Should we not specify the domains with -d toggle if our CSR includes the domains? Trying to figure out if we sh…

I don’t work for Let’s Encrypt but in my opinion it is a problem on their end, regardless of what you did in Certbot (improper use or not). Any chance you can post the contents of /var/cert_manager/certs/san132.csr? It would be very helpful.

I don’t work for Let’s Encrypt Woops! You seem so knowledgable on this forum :sweat_smile: The csr looks exactly as you'd expect. Here's the contents after decryption, with cryptographic info redacted: Certificate Request: Data: Version: 0 (0x0) Subject: Subject Pub…

[image] _az: First, a simple one. A subproblem’s type should not include the urn:ietf:params:acme:error: prefix twice. Second, the duplicate sub-problems does seem like a bug. While Let’s Encrypt does look up the CAA records multiple times per authorization (multi-VA, and assuming 8 hours has e…

I filed Subproblems' type includes the ACME URN namespace twice · Issue #4682 · letsencrypt/boulder · GitHub as well for the error namespace thing. [image] jsha: I’m pretty confident this isn’t a CAA re-checking bypass, but of course will keep a sharp eye on the possibility as I check the code. …

[image] _az: CAA checks ..., but it turned out to be because of tree climbing lol. Sorry, this is totally off here, one may split the topic. DNS tree climbing for CAA record is a huge design mistake in the RFC. That is my humble opinion. I have to write it down somewhere, this thing really f…

@jsha Do you understand the root cause of this “Rechecking” error that I’m hitting, or merely verifying that it’s not working as intended? We’re unable to renew certs right now and have about 8 more days until our potential “point of no return” and start expiring certs for production customers. All…

[image] lancedolan: @jsha Do you understand the root cause of this “Rechecking” error that I’m hitting, or merely verifying that it’s not working as intended? The problem I was looking at in this thread is that one CAA error (for admin.mrhs.hwrsd.org) was duplicated many times into other subp…

Rechecking caa fails with 99 identical subproblems

Help

rg305 February 18, 2020, 8:40pm 2

I’m confused…
You are using a .csr file and also detailing all the domains with -d in the same call.
That seems redundant.

Topic		Replies	Views
LetsEncrypt renewal error - Error finalizing order :: While processing CAA, SERVFAIL looking up CAA Help	9	1359	March 2, 2024
Problem at renewing a certificate (CAA) Help	11	2120	July 18, 2020
Spurious CAA SERVFAIL responses during finalize Help	40	1922	January 4, 2024
Consistent 500's for new-cert (failing CAA for one domain) Issuance Tech	17	4895	October 18, 2017
Certificate renewal fails: urn:ietf:params:acme:error:caa 403 Help	34	1699	January 11, 2024

Rechecking caa fails with 99 identical subproblems

Related topics