Skip to content

Cannot use the Venafi issuer with an Access Token when the VEDAuth IIS endpoint in TPP is configured to accept client certificates (local error: tls: no renegotiation) #5517

@maelvls

Description

@maelvls

As described in #3544 (comment), cert-manager has a bug that prevents using an Access Token along with a TPP server on which the VEDAuth IIS endpoint's "SSL Config" is set to "Accept". Here is a screenshot of a TPP instance in which I RDP'ed and that has "SSL Config" set to "Accept":

vedauth

With this configuration, cert-manager will show the following message in one of the conditions of your Venafi Issuer:

Error initializing issuer: Failed to setup Venafi issuer: client.VerifyCredentials: tppClient.VerifyAccessToken: Get "https://venafi-tpp.platform-ops.jetstack.net/vedauth/authorize/verify": local error: tls: no renegotiation

This bug (or rather, "limitation") is due to the fact that cert-manager does not accept TLS renegotiation, and we did not catch this earlier because there is no end-to-end test that uses an access token.

I don't think there is any reason for cert-manager not to allow TLS renegotiation. Note that TPP only ever requests to renegotiate once.

Reproducing the error

I reproduced this bug with cert-manager 1.9 and the Venafi issuer, using an access token and with TPP 20.4 with the "SSL Config" in the VEDAuth endpoint set to "Accept".

First, make sure you have access to Jetstack's test TPP (https://venafi-tpp.platform-ops.jetstack.net), or use a TPP instance where the VEDAuth endpoint has its "SSL Config" tab set to "Accept".

If you are a jetstacker, you can run the following to access to https://venafi-tpp.platform-ops.jetstack.net from the kind cluster that you will create afterwards (works on both Linux and macOS):

if ! docker network inspect kind 2>/dev/null; then docker network create kind >/dev/stderr; docker network inspect kind; fi | jq '.[].IPAM.Config[0] | select(.Gateway) | .Subnet' -r | sed 's|/16||'
sudo tee -a /etc/hosts <<<"$(kubectl get nodes -ojson | jq '.items[0].status.addresses[] | select(.type | contains("InternalIP")).address' -r | perl -p -e 's/^(\d+\.\d+\.\d+)\.\d+$/$1.1/;') venafi-tpp.platform-ops.jetstack.net"
docker run -d --restart=always --privileged --net=host --name socat alpine/socat tcp-listen:443,reuseaddr,fork tcp:localhost:8443 >/dev/null
docker run -d --restart=always --net=host -v ~/.config/gcloud:/config -e CLOUDSDK_CONFIG=/config -u $(id -u):$(id -g) --name tpp-tunnel gcr.io/google.com/cloudsdktool/google-cloud-cli:alpine \
        gcloud compute start-iap-tunnel venafi-tpp-dev 443 --local-host-port=0.0.0.0:8443 --project jetstack-platform-ops --zone europe-west1-b >/dev/null

Check that it works with the following command:

docker run --rm --net=kind alpine/curl -isS -o /dev/null -D/dev/stderr --show-error --fail --max-time 1 --retry 4 --retry-all-errors https://venafi-tpp.platform-ops.jetstack.net/

Then, create a kind cluster and install cert-manager:

kind create cluster
helm upgrade --install cert-manager jetstack/cert-manager --version 1.9.1 --namespace cert-manager --set installCRDs=true --create-namespace

Finally, create the Venafi issuer:

TOKEN=$(vcert getcred -u https://venafi-tpp.platform-ops.jetstack.net --username $VENAFI_TPP_USERNAME --password $VENAFI_TPP_PASSWORD --client-id=$VENAFI_TPP_CLIENT_ID --scope='certificate:manage' --format json | jq -r .access_token)
kubectl apply -f- <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: issuer-1
spec:
  venafi:
    zone: '\VED\Policy\Jetstack'
    tpp:
      url: "$VENAFI_TPP_URL"
      credentialsRef:
        name: issuer-1-credentials
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cert-1
spec:
  commonName: foo.bar
  dnsNames:
    - foo.bar
  issuerRef:
    kind: Issuer
    name: issuer-1
  secretName: cert-1
  privateKey:
    rotationPolicy: Never
---
apiVersion: v1
kind: Secret
metadata:
  name: issuer-1-credentials
stringData:
  access-token: $TOKEN
EOF

You should see the error message local error: tls: no renegotiation when running the following:

kubectl describe issuer issuer-1

/kind bug

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions