-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Fix ACME when mTLS with client CN check is enabled #11062
Conversation
This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The 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/test-infra repository. |
Welcome @bossm8! |
Hi @bossm8. 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 Once the patch is verified, the new status will be reflected by the 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/test-infra repository. |
✅ Deploy Preview for kubernetes-ingress-nginx canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
/hold for @Gacko
I don't see a reason to hold (especially not for me) if this looks good to you. /unhold |
I'm rather asking myself why there's mTLS on a non-HTTPS server. Do we support forwarding the Client Certificate DN in TLS offloading setups? |
the issue mentioned does not show |
/ok-to-test Long story short, acme challenges usually runs against http (not https), as you are asking for a new certificate, + you don't validate the caller. think on let's encrypt sending some challenge, and being blocked because you have enabled mTLS/clientcert on your side :) Thanks for the contribution |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bossm8, cpanato, rikatz 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:
Approvers can indicate their approval by writing |
Once again, I'm asking myself what's the use case for mTLS on HTTP (not HTTPS). Can one please enlighten me? :) |
The current implementation of the nginx templating does not allow to get mTLS when certificate CN matching is enabled (please see #10185) because no certificate can be requested for the server via ACME's HTTP challenge. This is because the well-known ACME endpoint is handled via the same |
(Could we thus reopen #10185?) |
For mTLS you would need a client certificate and you would normally hand that via HTTPS only. ACME on the other hand is handled via HTTP. So I'm asking myself why we are checking for a client certificate (HTTPS) in a HTTP block. That's probably done because there might be use cases where TLS is terminated before NGINX (offloading). |
I think your proposal is to change this logic to only happen when the connection is a tls one right? As we mix both listeners on the same server directive, we probably need some check like if ssl_protocols for the session is not false https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables |
That depends on where the "$ssl_client_s_dn" is coming from. I'm thinking of scenarios where an upstream load balancer is terminating SSL and passing the client certificate DN as a header. In that case we would still use HTTP... |
Good point! I think we set some variables based on a trust from loadbalancers (eg x-forwarded-* and the certs) but IIRC some variables are set per nginx listener directly and are RO. Anyway this needs to be think better. |
What this PR does / why we need it:
Described in #10185
CertManager will fail to create a certificate If we enable mTLS on an ingress with client CN match enabled:
If the annotation
nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=some-cn"
is removed it does not fail.The issue is that the client CN match is implemented too early (which makes sense - fail fast). The PR fixes this case
by only checking the client certificate for its CN if the location is not
.well-known/acme-challenge/...
.Types of changes
Which issue/s this PR fixes
fixes #10185
How Has This Been Tested?
The following configuration was mounted into a local
nginx
container (docker run --rm -v $PWD/default.conf:/etc/nginx/conf.d/default.conf -p 8080:80 nginx
:When running curl against this config we get
403
:The same command against this config:
returns
404
, which is expected since there is nothing on this url:While other urls still return
403
:This test should be sufficient as acme works on http. Similar is shown in #10185 when removing the
match-ch
annotation.Checklist: