It occurred to me that, while I had asked about this feature, I had never formally requested it in this category. So...now I am 
See reference on this page.
4 Likes
It’s on our priority list, but we can’t commit to any timeframe. It is a bit lower priority than other work we’re doing. Scale-up work to keep running and root program requirements have to go first. It’s getting close to the top of the pile though!
12 Likes
Thanks for your quick response, Matt! Glad that it is climbing to the top of the heap!
5 Likes
It would be really cool to have this, especially the accountURI part. In particular (for me) it would soften the argument against hosted DNS challenge response type services e.g. acme-dns, Certify DNS (which is our own cloud hosted implementation of acme-dns).
We have thousands of users using Certify DNS and it would be great to offer them that path for reassurance. I'm sure the hosted version of acme-dns (at auth.acme-dns.io) has many thousands of users as well.
6 Likes
What's the status of this feature in the staging environment? Is it ready for people to try to hammer away at to try to find holes, like someone making some equivalent of caatestsuite.com for the new parameters that tries to find all the edge cases and see how the system deals with them? Or is there a lot of actual coding that still needs to happen too in addition to the careful spec-reading and confirming that it won't immediately lead to some Dreaded Incidents?
6 Likes
I'd also imagine of the the biggest wins administrators would get from this is being able to use Let's Encrypt certs, but not allow just anyone to issue them. So for instance an org doesn't have to worry about a contractor coming in, getting a "dev" VM setup with a web app and then disappearing once the link has been handed to a bunch of users shadow-IT style.
5 Likes
Yes, please! It’s available in staging and the more testing, the better.
6 Likes
As an aside, this apparently doesn't work with Cloudflare DNS because they override the letsencrypt.org CAA record if you specify one, presumably so all their auto cert stuff continues to work normally.
3 Likes
Turning off Universal SSL removes these CAA records, right?
5 Likes
Thanks, yes it does. Also tested with a subdomain zone on ClouDNS and staging behaved as expected for both accountURI and validationmethods restrictions.
4 Likes
Well, I did a little bit of ad-hoc testing of the "validationmethods" parameter, and it was working pretty well (once I realized that the official ACME Validation Methods Registry uses all-lowercase labels even though the standard in LE's documentation is all-uppercase). The main thing I found so far that I'm not even sure of the correct answer is if the "validationmethods" parameter is set more than once on an "issue". I think it might be a correct reading that all the parameters with that name would constrain the Property. So I created a CAA record just consisting of
0 issue "letsencrypt.org; validationmethods=dns-01; validationmethods=http-01"
Which I think should prevent all issuance for that name since no methods actually fulfill both constraints. But in fact, I could issue a certificate (using http-01) for that name.
With the parameters the other way around (http-01 first, and dns-01 second), trying to use http-01 did give me a CAA error. So I think that Boulder is just using the last validationmethods in the list. (I suppose I could look in the source code, but I guess I'm starting with just black-box testing for now if I want to call it an intentional choice rather than just laziness.) Maybe that's even correct; I couldn't find in RFC 8657 or 8659 any clear direction on how duplicate properties were supposed to be handled.
I may play around some more, including maybe with "accounturi" as well, when I get some more time, but I thought I'd share what I found so far.
7 Likes
You made me curious so I looked too. It does instruct to use the parameter with multiple values rather than using multiple parameters. The text below is from its main section. In Examples section it shows using two CAA records with a single validationmethods value as alternate to multiple values. I don't know the style of these RFC's well enough to know whether they get more specific than this in other cases.
This document also defines the "validationmethods" CAA parameter for the "issue" and "issuewild" Properties. The value of this parameter, if specified, MUST be a comma-separated string of zero or more validation method labels.
A value string with zero labels. Hmmm
From Examples section:
example.com. IN CAA 0 issue "example.net; \
validationmethods=dns-01,xyz-01"
The following shows an equivalent way of expressing the same
restriction:
example.com. IN CAA 0 issue "example.net; validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01"
5 Likes
If I look the CAA parameter parser correctly, this for loop does not check if a certain parameter already exists in the "saved" parameter list and just overwrites any previously set parameters with the "latest" one, being the rightmost parameter:
5 Likes
Sorry if I wasn't clear: Using commas for multiple allowed validation methods worked fine in my testing. I was trying to do things "wrong" to see what happened.
Yeah, having a plain validationmethods= meant that it blocked issuance, which I believe was correct.
I do wonder, upon thinking of it more, just how "cached" validations are supposed to work with CAA (which I didn't really try testing). Would an empty validationmethods mean that only still-cached validations should be used? Or is it checking the "most recent" validation or the like?
Yeah, I was guessing it was doing something along those lines.
4 Likes
does validation/accountURL per CA allowed and working as expected?
for exemple
example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
example.com. IN CAA 0 issue "someCA.com; validationmethods=http-01,dns-01"
would this CAA disallow cert by http-01 by LE while allowing someCA to use http challange?
4 Likes
I believe so, yes.
4 Likes
No, I understood that. I was reacting to your comment about the RFC not being clear. I thought the specs reasonably described acceptable syntax. It does not appear the CA is responsible for reporting syntax errors. And, those can lead to unexpected outcomes. A full syntax assessment is probably best done by a generalized "lint" tool or Let's Debug.
Good question on cached validations. LE should make that clear in their FAQ about them. I now wonder what happens if even the CAA issue value were changed during the cached period. Would LE check CAA or fully rely on cache?
3 Likes
CAA RR are cached MUCH shorter than valide authz (8 hours instead of 30 days). In fact, the lack of maintaining this shorter cache time in certain situations has lead to a quite serious incident: 2020.02.29 CAA Rechecking Bug
5 Likes
The CAA RFC specifically says:
The semantics of parameters to T issue Property Tag are determined by the Issuer alone.
So the results of specifying a single parameter multiple times in the parameters section of a single CAA Resource Record Property Value are unspecified. I don't necessarily think that taking the last one (as we currently do) is the best thing to do, but it does appear to be a completely valid thing to do... in general.
Of course, the accounturi and validationmethods parameters are further specified, so let's see what those have to say:
A Property with multiple "accounturi" parameters is unsatisfiable.
So for accounturi parameters the behavior is well defined: multiple disagreeing parameters means issuance cannot happen because you cannot satisfy all of them at the same time.
A CA MUST only consider a Property with the "validationmethods" parameter to authorize issuance where the validation method being used is identified by one of the validation method labels listed in the comma-separated list.
This is much less clear. But I think it should probably be interpreted in the same way as accounturi above: issuance can only happen if the validation method being used appears in all validationmethods parameters in the resource record. So basically, take the intersection of all of the lists of methods, and hope that intersection is non-empty to allow issuance
3 Likes
Are you suggesting that for a single CAA record? Because the RFC Examples section shows below as identical to '=dns-01,xyz-01`. It two CAA records create a union then I think it odd if two on one CAA record would be treated as an intersection.
4 Likes