While TLS provides ConnectionState() to share some connection security info, like remote certificate (PeerCertificates), it lacks the info about local certificate used to set up a connection. And it's not always possible to predict local certificate used as the selection depends on the remote end requirements.
Exposing the local certificate would be very helpful for debugging connection issues, for example, user may find certificate getter returns suboptimal certificate, which may be expiring soon or having a long verification chain. Moreover, it will also enable collecting certificate usage statistics, which could be valuable for service owners.
We have a specific use case in grpc channelz feature. It presents to users the current state of a connection, including the info about what's the local/remote certificate has been used. Users may use it to figure out what's the identity it presents to the peer, how long local certificate will last before expired, etc. Moreover, channel trace could record local certificates tried and failed before, which may be helpful for diagnosing problematic setup.
GetCertificate and GetClientCertificate seems to be only part of the logic to select the local certificate, by reading the implementation of getCertificate function. If the returned result of GetCertificate and GetClientCertificate is nil, nil, then it will resort to NameToCertificate to find a certificate.
And yes, collocating local certificate with remote certificate in theConnectionState struct is convenient for usage.
Pinging this thread again to let y'all know that gRPC-Go is still interested in having this feature.
gRPC is adding support to secure service-to-service communication in our existing proxyless service mesh offering. Currently we use the local/remote certificates used by a connection in our e2e tests to verify that the expected certificates are used. Once this feature is public, this would definitely be helpful for our users in debugging real problems.