Don't error log when no OCSP responder URL exists

[zeeZ]

What happened:

With OCSP stapling support enabled, on every single request that serves a TLS certificate which does not contain OCSP information, the following error message is logged: [lua] certificate.lua:124: fetch_and_cache_ocsp_response(): could not extract OCSP responder URL: nil, context: ngx.timer, ...

What you expected to happen:

An unset OCSP responder URL in a certificate should not be an error. Especially not on every request.

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

NGINX Ingress controller Release: v1.3.0 Build: 2b7b74854d90ad9b4b96a5011b9e8b67d20bfb8f Repository: https://github.com/kubernetes/ingress-nginx nginx version: nginx/1.19.10

How to reproduce this issue:

kind create cluster
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/baremetal/deploy.yaml
echo "
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ingress-nginx-controller
    namespace: ingress-nginx
  data:
    enable-ocsp: 'true'
" | kubectl apply -f -
POD_NAME=$(kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/component=controller -o NAME)
kubectl exec -it -n ingress-nginx $POD_NAME -- curl -kH 'Host: foo.bar' https://localhost
kubectl -n ingress-nginx logs $POD_NAME

Anything else we need to know:

ocsp.get_ocsp_responder_from_der_chain() only returns a nil URL and error on FFI_DECLINED, which as far as I could tell is undocumented and seems to be the case when the call succeeded, but no such URL exists.

There's also a case where something is returned, but the error is also "truncated" that is being ignored.

Relevant OpenResty code: https://github.com/openresty/lua-resty-core/blob/v0.1.22/lib/ngx/ocsp.lua#L43-L70

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: zeeZ / name: Christian (c2171cd7d8aa63a42cfe092d66354778daa5b9b6)

[k8s-ci-robot]

@zeeZ: 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.

[k8s-ci-robot]

Hi @zeeZ. 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/test-infra repository.

[rikatz]

Nice catch, thanks /ok-to-test /lgtm /approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rikatz, zeeZ

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~~ [rikatz]

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