Restrict challenges for a domain

Feature Requests
1

Is it possible to restrict/limit verification for my domain to only the DNS-01 challenge? I don’t see any mention of this at Challenge Types, so I guess not. I’d like to request this feature then.

My rationale is that I’d like the option of not “blessing” IP-based security by providing certificates based on it. I’d rather allow only the DNS-01 challenge with DNSSEC. Not only could my ISP be compromised (or a route be hijacked) but I run some services on my home, dynamic IP-based Internet connection. The IP leases don’t last forever. If say my equipment goes down for a while, the lease could expire while my DNS still points to an IP that’s no longer mine. Some other customer can get my IP and then a certificate for my domain name.

I suppose I could use at least three mitigations for this:

  1. I can set up some kind of “dead man’s switch” to remove the DDNS entry if my server doesn’t check in, and arrange for heartbeat time < kill + DNS propagation time < lease time.

  2. I can watch the certificate transparency logs so I can know if this attack happens.

  3. I can pin my public key.

but the first two are cron jobs I have to keep maintaining to be secure, and the third has its own problems. It seems more approachable to do something once ahead of time (like add a configuration TXT record) instead.

2

https://tools.ietf.org/html/rfc8657#section-4 will do exactly what you want - not yet enabled in production but coming eventually …

You can testing it out on staging though, it’s working there.

3

What would happen if I had set the “validationmethods” parameter on a production domain CAA right now? Would LE production simply ignore it, or fail the validation?

4

Nothing, it's only active in staging, not the production endpoints. See ACME-CAA "validationmethods" support - #5 by jsha for more information.

5

wouldn’t it blocking if it’s set critical (and it doesn’t if not) as any other unknown CAA record CA can’t understand?

6

The critical flag only applies to the property tag (issue, issuewild, iodef, etc), rather to the property value itself.

But Let’s Encrypt could choose to block unrecognized parameters if it wanted to: Boulder ignores RFC 8657 accounturi

7

The CAA RFCs just say that the semantics of parameters are entirely up to the CA.

Let’s Encrypt – or the ACME WG – could decide that unknown parameters should block issuance, or even define some kind of “parameterscritical” parameter.

But the CAA RFCs do not prescribe anything about parameters.

(Note: I only skimmed RFC 8659 and did not check the BRs.)