[VC-31275] Allow user to configure the User-Agent HTTP header in vcert SDK

[wallrj]

Software like cert-manager can now supply its own User-Agent when it instantiates the vcert.Client.

Why? Because if there is a bug in the cert-manager Venafi issuer, which causes it to not back off in the event of a failed API request, the Venafi server administrator can quickly know that cert-manager is the culprit and quickly report the bug so that it be quickly fixed.

The default User-Agent for vcert CLI and for any software importing the vcert/v5 is now: vcert/v5.

Why? Because right now the vcert CLI and any software that uses the vcert SDK will use the default Go-http-client/1.1 User-Agent header and the requests will be indistinguishable from any other Go http client. The new default header will allow the Venafi administrator to estimate the adoption of vcert v5.

Fixes: https://github.com/Venafi/vcert/issues/437

• https://github.com/Venafi/vcert/issues/437
• VC-31275

Testing

vcert CLI default

export HTTPS_PROXY=localhost:8080
go run ./cmd/vcert renew     -k foo --no-prompt -id foo --trust-bundle ~/.mitmproxy/mitmproxy-ca.pem

vCert: 2024/03/27 10:54:54 Warning: --platform not set. Attempting to best-guess platform from connection flags
vCert: 2024/03/27 10:54:54 Detected trust bundle...
vCert: 2024/03/27 10:54:54 You specified a trust bundle.
vCert: 2024/03/27 10:54:55 Unable to connect to Venafi as a Service: vcert error: server error: 401 Unauthorized
vCert: 2024/03/27 10:54:55 Failed to fetch old certificate by id foo: must be autheticated to request a certificate
exit status 1

Examples

I've partially tested the examples, in so far as I ran each example with some fake settings in environment variables and observed that the expected User-Agent header was present in the first failing request.

• firefly

• server

• simple-cli

• tlspc-svc-account

[wallrj]

/cc @rvelaVenafi

Please review.