I’ve noticed that LE doesn’t seem to support the authz deletion described in section 6.4.2 of the ACME spec—at least, when I submit requests for this I get 405/“Method Not Allowed”.
The payload I’m sending is: {"delete":true,"resource":"authz"}
• Can someone confirm that the above is not supported in LE?
• Is there a target date for implementation?
• Is there a mechanism by which I can query the Boulder server to determine what it supports and what it doesn’t?
Boulder (the CA server) is currently written against the acme-01 draft for the most part, which doesn’t include that section. I’m not aware of any ETA for implementing acme-02.
A cursory glance over the acme-01 spec doesn’t seem to indicate any way of deleting an authz request. Is there no such method?
It’s a bit frustrating given that there’s a per-day rate limit on the number of pending authorizations. Does Boulder/LE delete the authz once a challenge fails?
I’ve been backing out of the challenge once I have the DCV file in place if I see that that file is not externally accessible. Is the better approach simply to let Boulder/LE mark the challenge as failed?
They won't be deleted IIRC, but they won't count against your rate limit (which only counts pending authorizations). (Yep, that's a possible rate limit bypass, but it's probably "good enough" in that it blocks most automation stuck in an infinite loop, which would fill up the database quite rapidly.)
I suppose that would work. I'd also think about sharding registrations in a way that would avoid this (i.e. one registration per user instead of one global registration for your whole app). That would add some complexity and implementation details would be specific to your use-case, so just something to think about.
We already dispensed with one-reg-per-user in light of the fact that we’ve got servers with thousands of users, and we don’t want to hit the registrations-per-time rate limit, either.
I see, that makes sense. Maybe shard them per day or hour or something similar (the actual interval depending on your estimated issuance/pending authz rate)?
It’s probably easier for us to do the check on our end prior to sending the authz request for a given domain: resolve DNS recursively to the server, then hit that IP address (with the right Host header) to fetch a temp file and verify access.
It’s still not perfect, as each directory could have a hammed-up .htaccess or what not, but it’s pretty close.
Not really, no. I haven’t been keeping track of all changes between -01 and -02, so I’m not even 100% certain if everything could be done in a backwards-compatible way or if there’s gonna be a separate endpoint for -02 (or the final RFC).