Let's Encrypt: Enabling Acme CAA Account and Method Binding
community.letsencrypt.org
Let's Encrypt: Enabling Acme CAA Account and Method Binding
1–6 of 6 posts
Re: Let's Encrypt: Enabling Acme CAA Account and Method Binding
#2As the author of the relevant RFC it's great to see this finally getting turned on. To my knowledge this is the first production deployment.
To Let's Encrypt, thanks for finally making this happen.
Re: Let's Encrypt: Enabling Acme CAA Account and Method Binding
#3As the author of the relevant RFC it's great to see this finally getting turned on. To my knowledge this is the first production deployment. To Let's Encrypt, thanks for finally making this happen.
Thankyou for creating this RFC. I can see benefits specifically around reducing sub-domain hijacking if people use this correctly. I just noticed they have working examples in the appendix. I am adding these to some of my domains now.
Re: Let's Encrypt: Enabling Acme CAA Account and Method Binding
#4Am I understanding correctly that these new fields must be included as part of the "issue" record, not as a record of its own? Right now, I have:
===
# dig CAA hass.a-rwx.org +short
0 iodef "mailto:admin@lesaker.org"
0 issue "letsencrypt.org"
0 issuewild ";"
===
Can I add an additional TXT record for "validationmethods=dns-01", or do I need to append it to the "issue" record?
Re: Let's Encrypt: Enabling Acme CAA Account and Method Binding
#5Am I understanding correctly that these new fields must be included as part of the "issue" record, not as a record of its own? Right now, I have: === # dig CAA hass.a-rwx.org +short 0 iodef "mailto:admin@lesaker.org" 0 issue "letsencrypt.org" 0 issuewild ";" === Can I add an additional TXT record for "validationmethods=dns-01", or do I need to append it to the "issue" record?
The way this works is, the part of a CAA record in quotes can have parameters added to it. These have been little used until now so many may not be familiar with this syntax but it's always been in the CAA spec. The examples at the end of the linked RFC are accurate.
For example:
;; Must match account URI
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/acme/account/uri"
;; Must match account URI -OR- use dns-01 validation method
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/acme/account/uri"
example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
;; Must match account URI -AND- use dns-01 validation method
example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://some/acme/account/uri"
I also just put up an article with some more explanation: https://www.devever.net/~hl/acme-caa-live
Re: Let's Encrypt: Enabling Acme CAA Account and Method Binding
#6Am I understanding correctly that these new fields must be included as part of the "issue" record, not as a record of its own? Right now, I have: === # dig CAA hass.a-rwx.org +short 0 iodef "mailto:admin@lesaker.org" 0 issue "letsencrypt.org" 0 issuewild ";" === Can I add an additional TXT record for "validationmethods=dns-01", or do I need to append it to the "issue" record?
The way this works is, the part of a CAA record in quotes can have parameters added to it. These have been little used until now so many may not be familiar with this syntax but it's always been in the CAA spec. The examples at the end of the linked RFC are accurate. For example: ;; Must match account URI example.com. IN CAA 0 issue "letsencrypt.org; accounturi= https://some/acme/account/uri " ;; Must match account U…
Ah wow, I did not catch that the parameters go inside the quoted issue string. My brain misread the examples as `issue "example.org"; validationmethods=dns-01`.
Thanks for the clarification!