Ingresses: Allow . in Exact and Prefix paths.

[ZPascal]

PR Summary: Enable “.” in path validation to support IETF well-known ACME paths

Summary

This PR updates path validation to allow the dot character, enabling standardized well-known endpoints such as /.well-known/acme-challenge/. It also adds tests that:

• Accept ACME HTTP-01 challenge paths under /.well-known/acme-challenge/ for both Prefix and Exact path types.
• Explicitly reject paths containing $, #, and newline characters.

Motivation

• IETF standards reserve /.well-known/ for well-known resources (RFC 5785), which ACME relies on for HTTP-01 challenges.
• ACME’s HTTP-01 challenge requires serving under /.well-known/acme-challenge/... (RFC 8555). Prior validation disallowed the dot, preventing compliant paths.
• We continue to disallow characters that are risky or ambiguous in reverse-proxy and config contexts.

What Changed

• Validation now permits “.” in the allowed character set for path segments, in addition to alphanumeric, _, -, and /.
• Tests:
  • Added valid cases for /.well-known/acme-challenge/ with both Prefix and Exact types.
  • Added invalid cases for paths containing $, #, and newline.

IETF RFC Alignment

• RFC 5785 & RFC 8615 (Well-Known URIs): This PR enables the /.well-known/... namespace, allowing standardized discovery endpoints and ACME challenges.
• RFC 8555 (ACME): Allows the HTTP-01 challenge path under /.well-known/acme-challenge/..., aligning with the ACME challenge location requirements.
• RFC 3986 (URI Syntax): Partially aligns with the unreserved character set in path segments by including “.”. The implementation remains intentionally conservative (see below).

Missing RFC Features and Intentional Restrictions

While this change improves standards alignment, it does not implement the full breadth of URI semantics defined by the IETF. Notable gaps and deliberate restrictions include:

• Full RFC 3986 path character set not supported:
  • Still disallows many reserved/sub-delimiter characters allowed by RFC 3986 path segments (e.g., ! $ & ' ( ) * + , ; = : @). Some of these are intentionally rejected to avoid misconfiguration or ambiguity.
  • Percent-encoding is not interpreted; only raw characters from the permitted subset are allowed.
• Fragment delimiter “#” is outright rejected (appropriate in practice, as fragments are client-side only, but stricter than generic RFC parsing behavior).
• Case sensitivity: The validator is case-insensitive, whereas RFC 3986 treats path segments as case-sensitive (only scheme and host are case-insensitive).
• RFC 5785 specificities:
  • The registry mandates the literal lowercase segment “.well-known”. The current case-insensitive matching does not enforce lowercase.
• RFC 8555 (ACME) specifics not enforced:
  • Token formatting: ACME expects a token segment with base64url characters (no padding), without additional path separators.
  • Trailing slash behavior and exact token file semantics are not validated; the validator only checks character classes, not per-endpoint structure.
• Normalization and dot-segment handling (e.g., . and ..) are not interpreted or canonicalized; they are just allowed as literal characters within the approved set.

These limitations are intentional to keep validation simple, predictable, and safe for this controller’s context. Further RFC compliance can be considered if needed, preferably with targeted, endpoint-specific validation (e.g., stricter checks only for /.well-known/acme-challenge).

Security and Compatibility

• Security: Continues to reject potentially hazardous characters ($, #, newline) that can cause parsing ambiguities or unsafe interpretations in downstream components.
• Backward compatibility: Existing valid paths remain valid. This loosens validation to include “.”, enabling well-known use cases without breaking prior configurations.

Testing

• Adds positive tests for well-known ACME challenge paths for both Prefix and Exact types.
• Adds negative tests for paths containing $, #, and newline characters to ensure they remain disallowed.

Documentation

• Consider updating user-facing docs to clarify:
  • The allowed path character subset.
  • Support for /.well-known/acme-challenge/ and common ACME integrations.
  • Known deviations from RFC semantics (case-insensitivity, restricted character set), and rationale.

What this PR does / why we need it:

The PR adds support for the IETF RFCs 5785, 8555, and 3986. It also solves #11176.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Which issue/s this PR fixes

fixes #11176

How Has This Been Tested?

I've executed the corresponding unit tests.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.

[netlify]

✅ Deploy Preview for kubernetes-ingress-nginx canceled.

Name	Link
🔨 Latest commit	2799837
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-ingress-nginx/deploys/68a3a94cefd5bf0008d28085

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ZPascal / name: Pascal Zimmermann (7e04818, 2799837)

[k8s-ci-robot]

Welcome @ZPascal!

It looks like this is your first PR to kubernetes/ingress-nginx 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/ingress-nginx has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @ZPascal. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Gacko]

/retitle Ingresses: Allow . in Exact and Prefix paths.
/triage accepted
/kind bug
/priority backlog
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Gacko, ZPascal

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Gacko]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Gacko]

/cherry-pick release-1.13

[Gacko]

/cherry-pick release-1.12

[k8s-infra-cherrypick-robot]

@Gacko: once the present PR merges, I will cherry-pick it on top of release-1.13 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.13

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-infra-cherrypick-robot]

@Gacko: once the present PR merges, I will cherry-pick it on top of release-1.12 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.12

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-infra-cherrypick-robot]

@Gacko: new pull request created: #13799

In response to this:

/cherry-pick release-1.13

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-infra-cherrypick-robot]

@Gacko: new pull request created: #13800

In response to this:

/cherry-pick release-1.12

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ZPascal]

Thank you @Gacko, for the fast review!