fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext [blocked on #13995]

[macastelaz]

Important

Draft, blocked on #13995. This branch is based on #13995's head, so until #13995 merges this PR also shows #13995's commits. Only the last commit (fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext) belongs to this PR. After #13995 merges I'll rebase onto agentic-identities-bound-token so the diff is just this fix. This must merge before the feature branch is merged to main.

Problem

When mTLS is active, InstantiatingHttpJsonChannelProvider.createHttpTransport() builds a Conscrypt SSLContext but initializes it with the JDK (SunJSSE) PKIX TrustManagerFactory. On TLS 1.3, Conscrypt passes authType "GENERIC" to the trust manager. SunJSSE's end-entity checks reject that authType for server certificates that are CA-issued and carry a KeyUsage extension, which includes Google front ends. So every mTLS HTTP/JSON handshake fails with:

javax.net.ssl.SSLHandshakeException: Unknown authType: GENERIC
Caused by: java.security.cert.CertificateException: Unknown authType: GENERIC

The bug is already on main, but there it only triggers when GOOGLE_API_USE_CLIENT_CERTIFICATE=true is set explicitly. #13995 enables mTLS automatically whenever a workload certificate config is present, so on Cloud Run (agent identity) every HTTP/JSON client fails by default. gRPC isn't affected. The non-mTLS path isn't affected either, because google-http-client already pairs Conscrypt with a provider-matched trust manager there.

Fix

Use Conscrypt's own PKIX TrustManagerFactory (TrustManagerFactory.getInstance("PKIX", conscryptProvider)) for the mTLS SSLContext. I called the JDK API directly rather than SslUtils.getPkixTrustManagerFactory(Provider), which only exists in google-http-client 2.2.0+.

Conscrypt's trust manager loads the same default trust store as the JDK. Verified on JDK 21: 174 anchors in both, the same set, and both honor -Djavax.net.ssl.trustStore overrides identically.

Testing

• New InstantiatingHttpJsonChannelProviderTls13Test: a local JDK TLS 1.3 server presents a CA-issued leaf with KeyUsage and requires a client certificate. The test asserts that the transport completes the request and presents its client certificate.

  • Without the fix: fails with Unknown authType: GENERIC.
  • With the fix: passes.
  • Skips when Conscrypt native or TLS 1.3 is unavailable.

• Existing InstantiatingHttpJsonChannelProviderTest: 14/14 pass.

• Tested together with feat(gax): support transparent retries during mTLS certificate rotations #13995's latest head, on JDK 21 with Conscrypt active, using feat(gax): support transparent retries during mTLS certificate rotations #13995's end-to-end harness: 22 scenarios with real KMS and BigQuery Storage GAPIC clients against local mTLS servers, where the certificate rotates on disk.

  • With this fix: all 22 pass. That includes HTTP/JSON rotation, in-flight calls during refresh, and stress with close(). The refreshed transport still uses Conscrypt's socket factory.
  • Without this fix: every HTTP/JSON mTLS scenario fails with Unknown authType: GENERIC. Limiting the test server to TLS 1.2 makes the error go away, which confirms that the TLS 1.3 authType is the trigger.
  • Logs: https://paste.googleplex.com/5563956459077632 (with fix), https://paste.googleplex.com/5467233782988800 (without fix, JDK 21 set)

• Live on Cloud Run (agent identity), combined feat: Enable Bound Token for Agentic Identities #13873 + feat(gax): support transparent retries during mTLS certificate rotations #13995 build, default env:

  	gRPC	HTTP/JSON
  Before	✅	❌ Unknown authType: GENERIC
  After	✅	✅ authenticated over mTLS with a bound token

[gemini-code-assist]

Code Review

This pull request introduces support for dynamic mTLS certificate rotation in both gRPC and HTTP/JSON transports. It adds utility methods in MtlsUtils to resolve and validate certificate configurations, implements a CertificateRotationTracker to monitor file fingerprints on disk, and updates ChannelPool and RefreshingHttpJsonChannel to perform thread-safe, hot-swapping of channels upon rotation. Additionally, it updates ApiResultRetryAlgorithm and AttemptCallable to handle UnauthenticatedException by triggering channel refreshes. I have reviewed the changes and identified two areas where error handling and messaging can be improved for robustness.

[gemini-code-assist]

If config.getCertPath() or config.getPrivateKeyPath() is null or empty, passing them to new File() will result in a NullPointerException. It is safer to validate that these paths are non-empty before attempting to instantiate File objects.

    String certPath = config.getCertPath();
    String keyPath = config.getPrivateKeyPath();
    if (Strings.isNullOrEmpty(certPath) || Strings.isNullOrEmpty(keyPath)) {
      String sourcePrefix =
          isDefaultConfig
              ? "referenced by default configuration '"
              : "referenced by configuration '";
      throw new IllegalStateException(
          "Certificate or private key path is missing in configuration '" + configPath + "'.");
    }
    File certFile = new File(certPath);
    File keyFile = new File(keyPath);
    if (!certFile.isFile() || !certFile.canRead() || !keyFile.isFile() || !keyFile.canRead()) {

[gemini-code-assist]

The exception message only mentions that the file does not exist or is not a file, but the condition also checks !certConfig.canRead(). If the file exists but is unreadable, the message would be misleading. Consider updating the message to include readability.

Suggested change

	if (!certConfig.isFile() || !certConfig.canRead()) {
	throw new CertificateSourceUnavailableException(
	"Certificate configuration file does not exist or is not a file: "
	+ certConfig.getAbsolutePath());
	if (!certConfig.isFile() || !certConfig.canRead()) {
	throw new CertificateSourceUnavailableException(
	"Certificate configuration file does not exist, is not a file, or is not readable: "
	+ certConfig.getAbsolutePath());