acmez

Two small correctness fixes so does what its doc comment says. Neither is a security issue: the caller controls both the order identifiers and the CSR, and the CA is still the real authority (Boulder rejects unknown identifier types outright). This is just the client-side fast path, so it should fail fast on inputs the CA is going to reject anyway, and it shouldn't reject inputs that are fine. URI SANs were skipped. reads DNS names, IPs, emails and the otherName extensions, but never . routes any SAN containing a slash into that field, and its doc comment lists URIs as a supported SAN type, so a CSR built by this package can carry a URI SAN that no order identifier covers and the check passes. I added them as type with a comment noting there's no registered ACME identifier type for URIs; the point is that they're accounted for rather than dropped. The comparison counted matches instead of comparing multisets. With order and CSR the lengths are equal, matches twice, and is never noticed, so it passes. The counting is wrong in the other direction too: an order and CSR that both legitimately list the same name twice got rejected, because the nested loop appended four matches for a two-element list. Replaced with a count map so each identifier on one side consumes exactly one on the other. Tests: added cases to for a URI SAN missing from the order, a URI that differs from the order, both duplicate-masking directions, and matching duplicates. Reverting the two source changes fails six of them: With the fix, , and all pass, and the existing cases are unchanged. Error message wording is untouched so the existing expectations still match. Happy to drop the URI half if you'd rather not introduce an unregistered identifier type, the two changes are independent.

The following log statement in is at info level: https://github.com/mholt/acmez/blob/v3.1.6/acme/ari.go#L223-L231 Other similar statements log at debug level, which results in _this_ being the only statement my application actually outputs during a normal run. Would you be opposed to changing this to debug level as well?

Add support for the ACME challenge type defined in draft-ietf-acme-dns-persist-00. Following the same pattern as (#42), this adds: constant field on the struct (the new field specific to this challenge type) helper (returns ) helper (constructs RFC 8659 issue-value syntax with accounturi and optional wildcard policy) Tests for both helpers No solver is included since acmez is bring-your-own-solver. The solver for dns-persist-01 is a no-op in practice since the TXT record is pre-provisioned. Related: caddyserver/caddy#7495