Nginx pod not handling the scenario when user is sending wrong ssl certificate

[adilGhaffarDev]

What happened:

Nginx pod not handling the scenario when user is sending wrong ssl certificate and pod is getting restarted. We saw this in the fuzz testing.
Error is following:

W0906 09:18:52.133846       7 controller.go:1449] Unexpected error validating SSL certificate “xxxxxxxxxxx” for server “xxxxxxxxxx”: x509: certificate is valid for xxxxxxx, not xxxxxxxx
W0906 09:18:52.133856       7 controller.go:1450] Validating certificate against DNS names. This will be deprecated in a future version
W0906 09:18:52.133863       7 controller.go:1455] SSL certificate "xxxxxxxxxx" does not contain a Common Name or Subject Alternative Name for server “xxxxxxxxxxxxx”: x509: certificate is valid for xxxxxxxxxxxxx, not xxxxxxxxxxxxx
W0906 09:18:52.133874       7 controller.go:1456] Using default certificate
2024/09/06 09:18:53 [crit] 2644#2644: *6856 SSL_do_handshake() failed (SSL: error:0A0000CD:SSL routines::invalid alert) while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:442
panic: runtime error: index out of range [2] with length 2

What you expected to happen:

pod should not go for restart and exit with proper error message.

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

NGINX Ingress controller
Release: v1.10.1
Build: 4fb5aac
Repository: https://github.com/kubernetes/ingress-nginx
nginx version: nginx/1.25.3
Kubernetes version (use kubectl version):

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 <ingresscontrollernamespace> 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 <appnamespace> 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]

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-sigs/prow repository.

[longwuyuan]

/remove-kind bug
/kind support

The data you have provided is limited to a few lines of log messages. That little data is not enough to reproduce the problem or analyze the problem to a possible cause.

If users configure secret tls with certificates that does not meet the requirement of a configured ingress, its not a problem in the controller code so there is no action item there for the project.

If the controller pod reboots, then the cause will be one of many many reasons and its does not mean that there is a problem to be solved in the controller code. Looking at the logs of the pod and the events in the cluster provides some hints on why the pod restarted. The controller code does not restart a pod just because a bad certificate was configured in the secret tls.

You can help out by answering the questions that are asked in the issue template. That may potentially provide the data to readers for analysis and useful comments.

[longwuyuan]

Its hard to keep issues open if there is no action item as it adds to the tally of open issues. So I am closing this issue for now. Please feel free to reopen the issues, after you have posted the information asked in the template of a new bug report. And kindly post a procedure that readers can copy/paste from and reproduce the problem, using a kind cluster.

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to this:

Its hard to keep issues open if there is no action item as it adds to the tally of open issues. So I am closing this issue for now. Please feel free to reopen the issues, after you have posted the information asked in the template of a new bug report. And kindly post a procedure that readers can copy/paste from and reproduce the problem, using a kind cluster.

/close

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.