The simplest CAA value is just an identifier for a CA. This type can be added today with relative ease already with no help from NPM. For Let's Encrypt this is just letsencrypt.org.
Let's Encrypt in particular allows specifying an account that's allowed to request certificates (and not just anyone who happens to be pointed at by the domain), as well as challenge types: https://letsencrypt.org/docs/caa/#what-to-put-in-the-record
Getting to Let's Encrypt account URI in NPM currently seems to require breaking into a container's data volume and finding it there.
It's located in: /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/$HASH/regr.json, which looks something like this:
Ideally, NPM could generate values for the CAA records, considering it knows the CA (Let's Encrypt), the account URI and the challenge type(-s?) it's going to use. The user would have to add the generated records manually, likely in their registrar's UI.
CAA restriction to a specific account would also mean that in an event of a data loss just spinning up a new instance of NPM at the same address is no longer enough and either:
a new Let's Encrypt account has to be created (which already happens automatically today) and CAA records updated to use the new one instead (a mild hassle, but it would work with no changes to NPM)
an existing account has to somehow be imported into certbot, meaning it'd have to previously be exported (both steps currently involve at least poking at the data volume)
Describe alternatives you've considered
At a minimum, I'd love access to the account URI somewhere in the web UI. That at least plugs the need to look into container's storage, but not having to look up Let's Encrypt's documentation for keywords like parameter names and values for challenge types would also be nice to have. Doing the rest manually isn't much of a problem.
CAA records on domains have an effect on their subdomains too
A single certificate generation definition doesn't necessarily have all the context to generate a CAA record, e. g. if NPM requests certificates for one domain using both HTTP and DNS challenges, CAA restrictions should probably allow both?.. So this probably shouldn't be a context menu item on certificates. A new dialog with a button at the top (next to "Add SSL Certificate" button) perhaps?
Is your feature request related to a problem? Please describe.
As a security hardening measure it's possible to advertise certificate issuing restrictions to CAs using DNS Certification Authority Authorization records (aka DNS CAA).
The simplest CAA value is just an identifier for a CA. This type can be added today with relative ease already with no help from NPM. For Let's Encrypt this is just
letsencrypt.org.Let's Encrypt in particular allows specifying an account that's allowed to request certificates (and not just anyone who happens to be pointed at by the domain), as well as challenge types: https://letsencrypt.org/docs/caa/#what-to-put-in-the-record
Getting to Let's Encrypt account URI in NPM currently seems to require breaking into a container's data volume and finding it there.
It's located in:
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/$HASH/regr.json, which looks something like this:Describe the solution you'd like
Ideally, NPM could generate values for the CAA records, considering it knows the CA (Let's Encrypt), the account URI and the challenge type(-s?) it's going to use. The user would have to add the generated records manually, likely in their registrar's UI.
CAA restriction to a specific account would also mean that in an event of a data loss just spinning up a new instance of NPM at the same address is no longer enough and either:
Describe alternatives you've considered
At a minimum, I'd love access to the account URI somewhere in the web UI. That at least plugs the need to look into container's storage, but not having to look up Let's Encrypt's documentation for keywords like parameter names and values for challenge types would also be nice to have. Doing the rest manually isn't much of a problem.
Additional context
A bunch of reading materials on CAA:
Notable gotchas: