Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to create a dns allow policy that can use sub-sub domains? #2053

Open
akumar-xyz opened this issue Nov 2, 2024 · 1 comment
Open

How to create a dns allow policy that can use sub-sub domains? #2053

akumar-xyz opened this issue Nov 2, 2024 · 1 comment
Assignees
Labels
needs triage Waiting for discussion / prioritization by team

Comments

@akumar-xyz
Copy link

akumar-xyz commented Nov 2, 2024

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to document this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Affected area/feature

When configuring CA issuance policy, how to allow all sub-sub domains i.e. wildcard that expands to multiple labels?

For clarity:

  1. *.acme.com
    • MATCHES xyz.acme.com
    • NOT MATCH xyz.cloud.acme.com
  2. *.*.acme.com - NOT ALLOWED (cannot parse permitted URI domain constraint "*.*.acme.com": URI domain constraint "*.*.acme.com" can only have wildcard as starting character)
  3. .acme.com - NOT ALLOWED (cannot parse permitted domain constraint ".acme.com": domain constraint ".acme.com" with wildcard should start with *)

I also tried 3 because RFC5280 states:

When the constraint begins with a period, it MAY be
expanded with one or more labels. That is, the constraint
".example.com" is satisfied by both host.example.com and
my.host.example.com. However, the constraint ".example.com" is not
satisfied by "example.com".

As far as I can tell, the matching rules are more similar to RFC2818 which would mean what I'm trying to do is not possible.

Is it possible to match for all sub-sub domains with just one rule? Something like **.acme.com?
Is the only solution to maintain a list of subdomains as well?

@akumar-xyz akumar-xyz added the needs triage Waiting for discussion / prioritization by team label Nov 2, 2024
@hslatman
Copy link
Member

hslatman commented Nov 4, 2024

Hey @akumar-xyz, thank you for opening the issue.

For the current implementation we decided our issuance policies had to be simple to configure, and thus we decided to put limits on the usage of the wildcard to a single label. While it's true that the evaluation rules are similar to how X509 Name Constraints are defined and evaluated, they're not exactly the same, the main reason for which is to keep things simple.

If you need wildcards on multiple labels you'll indeed need to keep track of the subdomains, and define a rule for each. Or instead of using an issuance policy, you can implement a webhook receiver to fully control when a certificate is allowed to be signed using our webhooks support.

@hslatman hslatman self-assigned this Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage Waiting for discussion / prioritization by team
Projects
None yet
Development

No branches or pull requests

2 participants