[gNMI] Verify optional client certificates

[ashutosh-agrawal]

Why I did it

The gNMI server supports an optional client-certificate mode for deployments that use password, JWT, certificate, or mixed application authentication.

The current optional mode uses tls.RequestClientCert. This asks the client for a certificate but does not verify a certificate when one is supplied. It also prevents certificate-based application authentication from receiving the verified certificate chain it requires.

The optional mode should continue allowing clients without certificates while verifying any certificate that a client chooses to provide.

This change deliberately preserves the existing application-authentication policy. It does not require client certificates for password or JWT clients, reject configurations without application authentication, change listener binding, or modify the no-TLS behavior.

How I did it

• Select tls.VerifyClientCertIfGiven when --allow_no_client_auth is enabled.
• Retain tls.RequireAndVerifyClientCert when optional mode is disabled.
• Update the flag description to state that a supplied certificate must be valid.
• Add TLS handshake coverage showing that:
  • a client may omit its certificate;
  • a trusted client certificate is accepted and verified; and
  • an untrusted client certificate is rejected.
• Add compatibility coverage confirming that optional client certificates continue to support:
  • no application authentication;
  • password authentication;
  • JWT authentication; and
  • mixed certificate/password authentication.

How to verify it

go test -mod=vendor -gcflags=all=-l ./telemetry \
  -run '^TestOptionalClientCertificate' -v

Results:

TestOptionalClientCertificatePolicy: PASS
  client certificate required: PASS
  client certificate optional and verified: PASS

TestOptionalClientCertificateHandshake: PASS
  certificate omitted: PASS
  trusted certificate: PASS
  untrusted certificate: PASS

TestOptionalClientCertificateApplicationAuthModes: PASS
  no application authentication: PASS
  password authentication: PASS
  JWT authentication: PASS
  certificate or password authentication: PASS

The new Go test file was formatted with gofmt, and git diff --check passed.

Which release branch to backport (provide reason below if selected)

• 202305
• 202311
• 202405
• 202411
• 202505
• 202511
• 202605

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO):
Failure type:

Tested branch

• master
• 202305
• 202311
• 202405
• 202411
• 202505
• 202511
• 202605
• N/A

Test result

• master: focused TLS policy, handshake, and application-authentication compatibility tests passed.

Description for the changelog

Verify client certificates supplied to the gNMI server when client certificates are optional.

Link to config_db schema for YANG module changes

N/A

A picture of a cute animal (not mandatory but encouraged)

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

review again

[qiluo-msft]

This PR fixes the RequestClientCert bug correctly — VerifyClientCertIfGiven is the right mode and the handshake tests directly verify the before/after behavior.

There is a related higher-impact issue worth tracking: in the SONiC image, telemetry.sh enables --allow_no_client_auth on every device where TELEMETRY|gnmi|client_auth is absent or false — the default out-of-box state:

# sonic-buildimage/dockers/docker-sonic-telemetry/telemetry.sh
CLIENT_AUTH=$(extract_field "$GNMI" ".client_auth")
if [ -z $CLIENT_AUTH ] || [ $CLIENT_AUTH == "false" ]; then
    TELEMETRY_ARGS+=" --allow_no_client_auth"
fi

This makes the flag opt-out rather than opt-in for production devices — the binary-level description of "requires explicit operator configuration" understates the actual exposure. A separate PR to sonic-buildimage changing the condition to [ "$CLIENT_AUTH" == "false" ] (drop the -z branch, require explicit configuration) would address the default-on behavior and is the higher-value half of the full fix.

This PR is still the necessary complement: even when the flag is intentionally set, any presented certificate should be verified — which RequestClientCert was not doing despite its comment claiming otherwise. Both fixes together close F032 fully.