-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
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":
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