Print the certificate SHA-1 thumbprint in the VCP e2e test

[wallrj-cyberark]

Motivation

test-e2e has been failing for several days, with the certificate never appearing in the Venafi inventory before the 300s deadline. Following one of those failures up means finding the certificate in the platform, and the SHA-1 thumbprint is what identifies it there. The common name is not a reliable search key.

This script prints neither. That is a problem specific to this test: it deletes its GKE cluster on the way out, so by the time anyone looks at a failed run the certificate is gone and the thumbprint cannot be recovered. This is not hypothetical — a debugging session earlier today stalled because nobody could produce the thumbprint for a run that had already finished.

What this does

Prints the thumbprint once after creating the Secret, and again in the timeout message, which is where you actually need it:

Certificate common name: venafi-kubernetes-agent-e2e.3e8db74e-0175-45f9-9652-c7d89c017744
Certificate SHA-1 fingerprint: 7675362C0FD7BF5CD62BB260A580F23BE82C5B6E

No behaviour changes. The only additions are one openssl invocation and three echos.

Test evidence

The thumbprint has to match what the platform stores, so I checked the pipeline two independent ways against the same certificate:

$ openssl x509 -in /tmp/t.crt -outform DER | openssl dgst -sha1 | awk '{print toupper($NF)}'
7675362C0FD7BF5CD62BB260A580F23BE82C5B6E

$ openssl x509 -in /tmp/t.crt -outform DER | sha1sum | awk '{print toupper($1)}'
7675362C0FD7BF5CD62BB260A580F23BE82C5B6E

Uppercase hex with no separators is the form the platform records, so it can be pasted into a log search unmodified.

bash -n hack/e2e/test.sh passes. I have dispatched e2e.yaml against this branch; I will link the run below once it finishes, so the new output can be seen in a real job.

[with Claude]

[wallrj-cyberark]

Dispatched e2e.yaml against this branch: run 35627632819. ark-test-e2e and ngts-test-e2e passed; test-e2e failed on the pre-existing inventory timeout, which is the case this change is for. The new output:

Certificate common name: venafi-kubernetes-agent-e2e.b9454362-a4d2-4dfd-a3ba-55e9791467f9
Certificate SHA-1 fingerprint: DA0EA0DD60EA8F24909502748733AB7057171139
...
Timed out after 300s waiting for certificate venafi-kubernetes-agent-e2e.b9454362-a4d2-4dfd-a3ba-55e9791467f9 to appear in the Venafi inventory
Search backend logs for the SHA-1 thumbprint DA0EA0DD60EA8F24909502748733AB7057171139, not the common name

The thumbprint was then enough to locate the certificate in the platform, which was the point — before this change that lookup was not possible once the job had torn down its cluster.