The auth-tls-match-cn shouldn't enable for http

[wenhug]

What happened:
If add "nginx.ingress.kubernetes.io/auth-tls-match-cn" annotation, it will add config like this
if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN }} ) { return 403 "client certificate unauthorized";}
This works for both http and https requests, all http requests will failed.

What you expected to happen:
Nginx don't verify client cert for http requests. All http requests also shouldn't check client cert matchCN .

NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Release: 1.2.1

Kubernetes version (use kubectl version):
1.23.12
Environment:

• Cloud provider or hardware configuration:

• OS (e.g. from /etc/os-release):

• Kernel (e.g. uname -a):

• Install tools:

  • Please mention how/where was the cluster created like kubeadm/kops/minikube/kind etc.

• Basic cluster related info:

  • kubectl version
  • kubectl get nodes -o wide

• How was the ingress-nginx-controller installed:

  • If helm was used then please show output of helm ls -A | grep -i ingress
  • If helm was used then please show output of helm -n <ingresscontrollernamepspace> get values <helmreleasename>
  • If helm was not used, then copy/paste the complete precise command used to install the controller, along with the flags and options used
  • if you have more than one instance of the ingress-nginx-controller installed in the same cluster, please provide details for all the instances

• Current State of the controller:

  • kubectl describe ingressclasses
  • kubectl -n <ingresscontrollernamespace> get all -A -o wide
  • kubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>
  • kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>

• Current state of ingress object, if applicable:

  • kubectl -n <appnnamespace> get all,ing -o wide
  • kubectl -n <appnamespace> describe ing <ingressname>
  • If applicable, then, your complete and exact curl/grpcurl command (redacted if required) and the reponse to the curl/grpcurl command with the -v flag

• Others:

  • Any other related information like ;
    • copy/paste of the snippet (if applicable)
    • kubectl describe ... of any custom configmap(s) created and in use
    • Any other related information that may help

How to reproduce this issue:

Anything else we need to know:

[k8s-ci-robot]

@wxyh: 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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

/remove-kind bug
/kind support

Lets wait for other comments, but auth-tls implies TLS so AFAIK http is plaintext so your expectation is invalid.

[schandbert]

We stumbled upon a possible issue using the combination of auth-tls-match-cn and automated certificate renewal with the certificate issuer. The acme challenge has no chance of getting successfully answered and will remain pending indefinitely. Afaik the certificate issuer sends a request like this:
curl http://our-hostname/.well-known/acme-challenge/iEZiyOECkBCOtdwyNUrZcVHrdT7kZi53zxkWNFRSbps answered by
HTTP/1.1 403 Forbidden client certificate unauthorized

In this special case TLS is not implied. Is there any known workaround we are missing?

[sherifkayad]

@schandbert check my comment here => #8582 (comment) .. maybe that could help

[schandbert]

@sherifkayad Excellent, works very well, thx. Hopefully the auth-tls-match-cn-feature gets enhanced in a similar manner.