mTLS with SAN/CN certificate validation

[alnhk]

opening the request here via github as this Support request or question relating to Ingress NGINX in Kubernetes Slack is not working and always hitting with ...doesn’t have an account on this workspace. and not allowing us to signup.

I am following this instruction - stackoverflow link1 and link2

Question mark - Assume the certificate contains this

%  openssl x509 -noout -subject -in acme-com.pem
subject=C = Hello, ST = World, L = Acme, O = "Hello, World.", CN = *.example.com

With help of nginx-ingress using nginx.ingress.kubernetes.io/configuration-snippet, how do we be able to validate the SAN or CN matching *.example.com ? for example We have this below mTLS and want to also ensure that the client certificate should also carry matching SAN or CN. As part of validation, if succeed, move forward otherwise deny.

  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-tls-secret: default/ca-cert
    nginx.ingress.kubernetes.io/auth-tls-verify-client: optional
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "3"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($ssl_client_verify = SUCCESS) {
        set $service_name "default-yes-mtls-backend-80";
      }
.. 
...

Is this something can be done ? Yes - came across this below page mentioning nginx.ingress.kubernetes.io/auth-tls-ssl-client-subject-dn, can validation check happen on this for instance this ?

Can an examples for nginx.ingress.kubernetes.io/auth-tls-ssl-client-subject-dn with validation check be shared ?

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[longwuyuan]

the link seems correct https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#client-certificate-authentication

/remove-kind bug

https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/

[alnhk]

@longwuyuan : not getting the answer from you at all. PLease share accordingly.

[longwuyuan]

You have not answered any questions asked in the new issue template, so while there is some information here, there is not enough to take any action or reproduce your problem.

Here is a example mTLS i found on internet https://mjpereira.medium.com/mutual-tls-with-ingress-nginx-controller-83b181f3bee0

[github-actions[bot]]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

[longwuyuan]

@alnhk sorry my earlier answer was not directly relevant to your questions.

Visiting this after such a long time, I see that if an example has to be provided, then it requires creation of certificates and images with a server listening on HTTPS. It also means the cert can not be self-signed as the CA will have to be injected into the controller for backend-protocol: HTTPS (since the self signed CA will not be known to the controller). And then there is the certs that the curl client needs.

This is all work to be done and hopefully gets done. But there is lack of resources for doing research & experiments. In fact we are deprecating features because we can not support them.

I was wondering if you can actually use the annotations you mentioned because they are the correct ones and do a test on a cluster created with the Kind tool. Because you will have your certs and app with HTTPS etc etc. If there is a problem there, then posting all the relevant data here can be one way to analyze this. Helpful comments to solve the problem will be easier that way.

If this is no longer a issue as its been a while, please confirm and close this case. It is adding to the tally of open issues and not tracking any action item so I would like to close the issue, if there is no action item being tracked.

/support

[longwuyuan]

/kind support /triage needs-information

It is possible that this is not relevant anymore based on the extended lack of activity. I will close it for now as it is adding to the tally of open issues and its not tracking any action item on any party. If it becomes relevant then please feel free to reopen the update with tests using recent releases of the controller.

There is extreme lack of resources so hard to allocate resources for research, experiment on triaging issues that take lot of work.

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to [this](https://github.com/kubernetes/ingress-nginx/issues/10488#issuecomment-2355132305): >/kind support >/triage needs-information > >It is possible that this is not relevant anymore based on the extended lack of activity. I will close it for now as it is adding to the tally of open issues and its not tracking any action item on any party. If it becomes relevant then please feel free to reopen the update with tests using recent releases of the controller. > >There is extreme lack of resources so hard to allocate resources for research, experiment on triaging issues that take lot of work. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.