ACME-CAA "validationmethods" support

API Announcements
1

On Wednesday May 30th (later this afternoon) (the change is live as of 16:44 UTC) we will enable support for the validationmethods restriction from the ACME-CAA draft standard in staging. This standard will allow you to restrict which ACME challenge types (dns-01 or http-01) can be used to validate your domains via a validationmethods CAA record extension. If you’re interested, we encourage you to test this feature with your domains in preparation for a production launch. We look forward to your feedback! If you’re not interested, you don’t need to do anything.

To use this new feature, add the validationmethods extension to your CAA record’s issue directive:

To allow only DNS-01 issuance update the CAA record value to:

  • issue "letsencrypt.org; validationmethods=dns-01"

To allow only HTTP-01 issuance (note this will preclude wildcard issuance which requires DNS-01) update the CAA record value to:

  • issue "letsencrypt.org; validationmethods=http-01"

Subdomains can override the CAA policy set by parent domains. Please see our CAA documentation for more information about CAA. You may also find the SSLMate CAA Record Generator useful. Keep in mind that validation-methods is currently only a draft, and is not honored by other CAs.

We also want to extend a big thank you to the two community members who worked on implementing this feature in Boulder, @4a6f656c and @lukaslihotzki :clap: :trophy: .

Thanks!

Edit: Updated to reflect that the change did not go live as planned yesterday and will instead be enabled in staging today. Apologies for the delay.

Edit 2: Updated to reflect that this is now live in staging as of ~16:44 UTC

Edit 3: Updated to reflect ACME-CAA draft-05 removing the dash (-) character in the validation-methods and account-uri parameters.

15 Likes
2

This feature is now live in staging.

3 Likes
3

The other piece of the ACME-CAA draft, the accounturi parameter is also live now in staging. Details of how to use it are in the draft: https://tools.ietf.org/html/draft-ietf-acme-caa-05.

3 Likes
4

Note: The ACME-CAA draft standard changed the parameter names between draft-04 (our original implementation) and draft-05 (the implementation now live in staging). The only change is the removal of the dash (-) character from the validation-methods and account-uri parameters. The CAA specification (RFC 6844) does not allow dash characters and so the new ACME-CAA parameters are validationmethods and accounturi. I have updated the API announcement accordingly.

3 Likes
5

As part of staging deployment, we uncovered a spec bug: How do you combine two parameters (i.e. accounturi and validationmethods) in a single CAA record? Are they separate by semicolons? Unfortunately RFC 6844 is ambiguous on this topic, though RFC 6844bis (a draft) fixes it by clearly specifying semicolons. We’ve started a thread to discuss: https://mailarchive.ietf.org/arch/msg/acme/7Wuzl7-fqbMR_04jQNawQqEF17E.

We’re currently blocked on moving this thread to production based on the outcome of that conversation. We don’t want to deploy something to production that may cause interoperability issues, so we want to ensure we’ve accurately characterized any potential issues before we proceed.

4 Likes
6

Brief update: We’re blocked on deploying this to production waiting on a CABF ballot to be adopted giving us permission to reference RFC 6844 errata for the original ambiguous grammar ahead of a longer term switch to RFC 6844-bis.

3 Likes