NginxProxyManager / NginxProxyManager/nginx-proxy-manager
DNS CAA record generation
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 34.2k
- Forks
- 3.9k
- Avg merge
- 21h 12m
- Merged PRs (30d)
- 20
Description
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:
{"body": {}, "uri": "https://acme-v02.api.letsencrypt.org/acme/acct/12345678"}
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:
- 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.
Additional context
A bunch of reading materials on CAA:
Notable gotchas:
- 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?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the Let's Encrypt account metadata at /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/$HASH/regr.json and the existing certificate-management web UI. Done means exposing the account URI and presenting usable CAA values for the CA, account, and applicable challenge types, while accounting for certificates that use multiple challenges.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100