fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext by macastelaz · Pull Request #14556 · googleapis/google-cloud-java

macastelaz · 2026-09-30T16:41:53Z

Important

This must merge before the agentic-identities-bound-token feature branch is merged to main. Without it, HTTP/JSON clients fail by default wherever mTLS is enabled automatically (see below).

Problem

When mTLS is active, InstantiatingHttpJsonChannelProvider.configureMtls() 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. On this feature branch, #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.

A second provider mismatch shows up on JDK 26: the mTLS SSLContext also used the JDK's default (SunX509) KeyManagerFactory. Since JDK 26 (JDK-8359956), that key manager applies algorithm constraints to the client certificate. Called from a Conscrypt handshake, it rejects valid certificates (e.g. SHA256withRSA), so the client sends an empty certificate chain and the server aborts with certificate_required.

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+.

Likewise, use Conscrypt's own KeyManagerFactory (KeyManagerFactory.getInstance("PKIX", conscryptProvider)), so the trust manager and key manager both come from the same provider as the SSLContext.

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.
Full gax-httpjson suite on the current agentic-identities-bound-token (with feat(gax): support transparent retries during mTLS certificate rotations #13995 merged): 194/194 pass on JDK 8, 11, 17, 21, 25 and 26. On JDK 26, the Tls13 test fails without the KeyManagerFactory change: the client sends an empty certificate chain and times out.
End-to-end with feat(gax): support transparent retries during mTLS certificate rotations #13995's certificate-rotation support, on JDK 21 with Conscrypt active: 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.

…ons (#13995) ## Description This PR adds transparent retries for mTLS workload certificate rotation to the gRPC and HTTP/JSON transports. When a request fails with `UNAUTHENTICATED` and the workload certificate on disk has changed, the transport is rebuilt with the new certificate and the request is retried once, without interrupting in-flight RPCs or streams. ### 🚀 Core Features & Architectural Updates • Rotation detection: `CertificateRotationTracker` compares the SHA-256 fingerprint of the workload certificate on disk with the certificate the transport was built with. The check only runs after an auth failure (never on the request path), and positive results are cached for at most 1 second so a burst of failures doesn't trigger a burst of file reads. Empty or mid-write files are ignored. • gRPC: `ChannelPool` replaces all of its channels when a rotation is detected. Calls already in flight finish on their old channels, which are shut down once idle. During a rotation refresh, a channel that can't be recreated is dropped rather than kept, so no traffic keeps using the old certificate; a statically sized pool is refilled in the background. • HTTP/JSON: `RefreshingHttpJsonChannel` swaps the channel's `HttpTransport` for one built with the new certificate. Calls already created keep using the transport they started with, so in-flight requests aren't interrupted. • Retries: `AttemptCallable` (unary) and `ServerStreamingAttemptCallable` (server streaming) refresh the transport after an `UNAUTHENTICATED` failure. If the transport moved to a new certificate during or after the attempt, the failure is flagged for a single immediate retry on the refreshed channel; its configured `isRetryable()` value is unchanged. • `ApiResultRetryAlgorithm` gives that retry once, immediately, without using a regular attempt. • If the free retry also fails after another rotation, the call stops instead of falling back to backoff retries. • For server streams, the free retry becomes available again once the stream has made progress, and the stream resumes through the existing resumption strategy. • Client and bidi streams refresh the transport on `UNAUTHENTICATED` but don't retry; the next stream uses the new certificate. • Plumbing: `TransportChannel` gains `shouldRefresh()`, `refresh()` and `getGeneration()`, which default to no-ops. `ApiCallContext.getTransportChannel()` gives retrying callables access to the channel, and `GrpcCallContext` / `HttpJsonCallContext` carry it through `merge()` and `withChannel()`. ### 🔒 System Hardening & Bug Fixes • Outstanding RPC leak (`ChannelPool.ReleasingClientCall`): if a call was cancelled before `start()`, `start()` threw without releasing the channel entry, leaving the channel with a permanently outstanding RPC count so it could never be cleaned up after a refresh. The entry is now released on that path and on cancellation before start. • HTTP/JSON refresh vs. shutdown: `shutdown()` / `shutdownNow()` are serialized with `refresh()` so a transport swap can't race with teardown. ### ⚠️ Behavioral & Security Boundary Changes * mTLS is enabled automatically when a workload certificate config is present (`MtlsUtils`, auth library): * When `GOOGLE_API_CERTIFICATE_CONFIG`, or the default gcloud `certificate_config.json`, contains a `workload` certificate, client certificates are used even if `GOOGLE_API_USE_CLIENT_CERTIFICATE` is unset. * `GOOGLE_API_USE_CLIENT_CERTIFICATE=false` still turns mTLS off. * mTLS misconfiguration now fails closed (`MtlsUtils`): * Previously, an invalid explicit config was swallowed and the client silently connected without mTLS. * Now client creation throws `IllegalStateException` in these cases: * the explicit `GOOGLE_API_CERTIFICATE_CONFIG` file is missing, unreadable or malformed; * the default config file exists but is unreadable or malformed; * a configured certificate or key file can't be read. * When mTLS is required but the transport can't load the client certificate, gRPC and HTTP/JSON channel creation fails with an `IOException` instead of falling back to a non-mTLS connection. ### 🧪 Testing #### Automated Testing • Added and updated comprehensive unit-tests reflecting the thread-safety fixes inside ChannelPoolTest.java and RefreshingHttpJsonChannelTest.java. • Corrected edge case test configurations to leverage realistic mocked X.509 certificates to properly exercise deep WorkloadCertificateUtils. getCertificateFingerprint() filesystem caching mechanisms. #### Manual Testing End-to-end tests with real generated GAPIC clients against local mTLS servers, run on this PR's head. Each scenario runs in its own JVM and checks the exact sequence of client certificates and outcomes the server saw. * **Setup** * Clients: `KeyManagementServiceClient` over gRPC and HTTP/JSON, and `GrpcBigQueryReadStub` for server-streaming `ReadRows` with offset-based resumption. * Servers: local gRPC and HTTPS servers that require a client certificate and return `UNAUTHENTICATED` / 401 for "revoked" certificates (by CN). * Rotation: the workload certificate under `GOOGLE_API_CERTIFICATE_CONFIG` is replaced by atomic rename, key first, then cert. * **gRPC unary:** * basic rotation: one rejected attempt, then a free retry on the new cert, and no extra attempts afterwards; * the server rejects every cert: one free retry, then stop; * a second rotation during the free retry: stops after 2 attempts, with no backoff retry; * UNAVAILABLE, then rotation; * corrupt cert on disk: no crash, the call fails, and the client recovers once a valid cert is written; * 20-call bursts across 2 rotations less than 1s apart: all succeed with exactly 1 refresh each; * a 3-channel pool: no stale channel after refresh; * 8 threads across 4 rotations, then `close()` with calls in flight: 70,624/70,624 calls succeeded, no hangs. * **gRPC server streaming:** * rotation before the stream starts; * rotation mid-stream: resumes at the right offset with no gaps or duplicates; * rotation retry re-armed after the stream makes progress, following an earlier UNAVAILABLE retry; * bounded: a second rotation without progress stops the stream, with no third attempt. * **HTTP/JSON:** basic rotation; reject-all; double rotation; a slow call started before rotation completes on the old cert while new calls use the new cert; corrupt cert, then restore; 8-thread stress with 4 rotations, then `close()` (49,561/49,561 calls succeeded, no hangs). The socket factory was verified for both Conscrypt and plain JDK TLS. * **No mTLS** (`GOOGLE_API_USE_CLIENT_CERTIFICATE=false`, or no certificate config): a single attempt with no client cert and no refresh, over both gRPC and HTTP/JSON, even when the cert files on disk change. * **Results:** * JDK 26 (JDK TLS): all 22 scenarios pass. * JDK 21 (Conscrypt): all gRPC, streaming and no-mTLS scenarios pass. * HTTP/JSON with mTLS and Conscrypt on TLS 1.3 fails with an existing `Unknown authType: GENERIC` handshake error, which #14556 fixes. With #14556 applied on top of this PR, all 22 scenarios pass on JDK 21 with Conscrypt active. * Harness source: https://paste.googleplex.com/6120902048219136 * Logs: https://paste.googleplex.com/5467233782988800 (this PR on JDK 26 and JDK 21), https://paste.googleplex.com/5563956459077632 (this PR + #14556 on JDK 21)

The mTLS HttpTransport paired a Conscrypt SSLContext with the JDK (SunJSSE) PKIX TrustManagerFactory. On TLS 1.3 Conscrypt passes authType "GENERIC" to the trust manager, which SunJSSE rejects for CA-issued server certificates with a KeyUsage extension (e.g. Google front ends), so every mTLS HTTP/JSON handshake failed with "Unknown authType: GENERIC". Since this PR enables mTLS automatically when a workload certificate config is present, this broke HTTP/JSON clients by default on Cloud Run. Use Conscrypt's own PKIX TrustManagerFactory, which loads the same default trust store (including javax.net.ssl.trustStore overrides) as the JDK. Adds a TLS 1.3 handshake regression test against a local server presenting a CA-issued leaf with KeyUsage and requiring a client certificate.

Assumptions.assumeTrue requires opentest4j (TestAbortedException), which is not on the Bazel test classpath, breaking the sdk-platform-java integration jobs. A class-level @EnabledIf condition has the same skip semantics without that dependency.

Since JDK 26 (JDK-8359956) the JDK's SunX509 key manager applies algorithm constraints to the client certificate. When called from a Conscrypt handshake it rejects valid certificates (e.g. SHA256withRSA), so no client certificate is sent and mTLS HTTP/JSON handshakes fail. Take the key manager from Conscrypt, matching the trust manager.

lqiu96 · 2026-10-07T15:03:58Z

+      } finally {
+        response.disconnect();
+      }
+      assertThat(clientCertificatePresented.get(10, TimeUnit.SECONDS)).isTrue();


looking at the logic, this doesn't seem like it would take that long. Is this to guard against it running forever? If it does take an unknown amount of time, can we use awaitility here?

Yes, it's just a fail-safe bound on Future.get() to guard against hanging forever if the server thread stalls. Since .execute() above is synchronous, the server has already completed the handshake and written the response by the time we reach this line, so Future.get() returns immediately without polling (and awaitility isn't currently on the gax-httpjson Maven/Bazel test classpaths). Added a one-line comment above it to clarify.

lqiu96 · 2026-10-07T15:41:45Z

    SslUtils.initSslContext(
        sslContext,
        null,
-        SslUtils.getPkixTrustManagerFactory(),
+        TrustManagerFactory.getInstance("PKIX", conscryptProvider),
        mtlsKeyStore,
        "",
-        SslUtils.getDefaultKeyManagerFactory());
+        KeyManagerFactory.getInstance("PKIX", conscryptProvider));


Thanks for this fix. Looks like would be ideal if the upstream http-client initialized with PKIX by default, so this could all just be done within builder.trustCertificates. In my mind, we don't need this override (L219-244). But since SslUtils.getDefaultKeyManagerFactory() looks to default with SunX509 and changing that is a behavior breaking change, I think this is the best we can do.

Can you add a small note of the above. e.g. Http-client looks to initialize with the default of SunX509 which is not supported by Conscrypt.

Added a note in the comment explaining that google-http-client's trustCertificates() initializes with the default SunX509 KeyManagerFactory, which is not supported by Conscrypt.

…eout

…te-bound ID tokens (#14559) > [!IMPORTANT] > **This must merge before the `agentic-identities-bound-token` feature branch is merged to `main`.** Docs PR #14557 documents this option. ## Why When an agent identity certificate is available, `ComputeEngineCredentials` requests certificate-bound ID tokens by default. A bound ID token is only accepted by targets that authenticate the caller over mTLS with the same certificate. Targets reached over standard HTTPS, such as a Cloud Run service's `*.run.app` URL or a custom domain, reject it with `401 Unauthorized`. Per the [ID token binding 1-pager](https://docs.google.com/document/d/1yL_xdDimlUlUyid6HDtqZUIMQjX9VznwzXn1SBABjZc/edit?pli=1&resourcekey=0-GxSXGdfH5Ni_nSI9f7xkQg&tab=t.0#heading=h.94fnt3dk2gx) (Sep 30 decision), ID tokens stay bound by default, and callers get a per-target `bind_id_token` setting to turn binding off where needed. The process-wide opt-out (`GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false`) is unchanged. ## What changes - New `IdTokenProvider.Option.DISABLE_BOUND_ID_TOKEN`. Callers pass it per target, the same way as `FORMAT_FULL` and `LICENSES_TRUE`: ```java IdTokenCredentials.newBuilder() .setIdTokenProvider((IdTokenProvider) credentials) .setTargetAudience("https://my-service-12345.us-central1.run.app") .setOptions(Arrays.asList(IdTokenProvider.Option.DISABLE_BOUND_ID_TOKEN)) .build(); ``` - `ComputeEngineCredentials.idTokenWithAudience()`: with the option, the certificate lookup is skipped and the identity endpoint is called with a plain GET. Without it, behavior is unchanged (bound whenever a certificate is available and binding isn't turned off by the env var). - Other credential types (`ServiceAccountCredentials`, `ImpersonatedCredentials`, `UserCredentials`) already ignore options they don't use, so the same code works outside agent identity environments. - Access tokens are unaffected. ### API shape `Option` is a set of on/off flags rather than a value, so this adds only the "off" flag (`DISABLE_BOUND_ID_TOKEN`). Leaving it unset means "auto", which currently means bound. This matches the 1-pager's tri-state (unset = auto) without adding an "enable" flag that would do nothing today; one can be added later without breaking callers if "auto" starts deciding per target. Python exposes the same control as `bind_id_token: Optional[bool]` (googleapis/google-cloud-python#18559). ## Tests ### Unit tests New `ComputeEngineCredentialsTest` cases, all with an agent identity certificate present and binding enabled: - `idTokenWithAudience_disableBoundIdToken_requestsUnboundToken`: GET, no request body, no forced `format=full`. - `idTokenWithAudience_disableBoundIdTokenWithFormatFull_requestsUnboundFullToken`: still GET; `format=full` is kept when the caller asks for it. - `idTokenWithAudience_disableBoundIdToken_skipsCertificateLookup`: with a certificate config pointing to a missing file, the default request fails, but the opted-out request succeeds, which shows the certificate is never read. - `idTokenCredentials_withDisableBoundIdTokenOption_requestsUnboundToken`: the option set on `IdTokenCredentials` reaches `ComputeEngineCredentials`. The existing bound-ID-token tests are unchanged and still pass. Full `oauth2_http` suite: 1064 tests, 0 failures. `fmt` is clean. ### Live test on GKE Run on a GKE cluster with agent identity enabled, using a test-only local merge of this PR with #14595 (GKE support) and #14556 (already on the base branch). A single process fetches ID tokens through `IdTokenCredentials` from `ComputeEngineCredentials` (ADC) and sends them to an agent-to-agent receiver pod. The receiver accepts only bound tokens over mTLS (whose `cnf` must match the client certificate), and only unbound tokens over plain HTTP. | Check | Defaults | `GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false` | |---|---|---| | ID token with `DISABLE_BOUND_ID_TOKEN` | **unbound** (no `cnf`); receiver: plain HTTP 200, mTLS 401 | unbound | | ID token for another target without the option, same credentials, fetched afterwards | **still bound** (`cnf` = certificate leaf); receiver: mTLS 200 | unbound | | Access token after the ID-token opt-out | **still bound** (401 on a plain, non-mTLS endpoint) | unbound | The option unbinds only the ID token it's set on. Other targets and access tokens are unaffected, and it's harmless when binding is already off. **Internal links (Googlers only):** [results](https://paste.googleplex.com/5926225961418752) · [harness](https://paste.googleplex.com/5713819712749568) · cluster [setup](https://paste.googleplex.com/5635555912712192) and [manifests](https://paste.googleplex.com/6258309762514944) (shared with #14595)

…kens and mTLS (#14595) ## Why GKE delivers agent identity credentials (Pod Certificates) as a single combined PEM file, holding the certificate chain and a PKCS#8 private key, at: ``` /var/run/secrets/workload-spiffe-credentials/x509.credential-bundle.private-key.pem ``` The feature branch already handles Cloud Run, where a certificate config points into the well-known directory. On GKE there is no certificate config, so neither the transport nor the token side found the certificate. This is the Java counterpart of googleapis/google-cloud-python#18559. Background: go/gke-security-identity/features/agent_identity_diy.md and go/sdk-mds-bound-token. ## What changes When **no certificate configuration exists** (`GOOGLE_API_CERTIFICATE_CONFIG` is unset and there is no `~/.config/gcloud/certificate_config.json`), a readable, non-empty bundle now: - **Transport:** turns on mTLS automatically. - `MtlsUtils.getWorkloadCertPath` / `useMtlsClientCertificate` return the bundle path. - `DefaultMtlsProviderFactory.create()` builds its keystore from the bundle via a new package-private `X509Provider.createForTransport()`. - Every GAX transport (`EndpointContext`, gRPC, HTTP/JSON) goes through that factory. - **Tokens:** `AgentIdentityUtils` resolves the same bundle, so `ComputeEngineCredentials` requests tokens bound to the certificate the transport presents. - With `GOOGLE_API_USE_CLIENT_CERTIFICATE=true`, the bundle takes precedence over the Cloud Run well-known files for the same reason. **Kept unchanged:** - `GOOGLE_API_USE_CLIENT_CERTIFICATE=false` and `GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false` still opt out. - An explicit or default certificate config (including ECP) always beats the bundle, on both sides. - **The bundle is never polled for.** GKE writes it before the container starts, and polling for a missing file would delay every workload that isn't an agent. - **Workload identity federation X.509 is unchanged.** The public `X509Provider` constructors don't fall back to the bundle. Only the transport factory does. - If the bundle disappears during the read (rotation), the transport reports `CertificateSourceUnavailableException` rather than a generic `IOException`. If it's briefly missing after a credential was cached, the token side falls back to the cached credential, but only while the bundle is still allowed (no certificate configuration has appeared). **New API:** a public static `MtlsUtils.hasCertificateConfiguration(...)` on an `@InternalApi` class. This is additive only. ## Differences from Python (intentional) - Python also checks `CLOUDSDK_CONTEXT_AWARE_CERTIFICATE_CONFIG_FILE_PATH`. Java has no equivalent env var. - Python temporarily keeps default **ID tokens** unbound on Cloud Run (when `GOOGLE_API_CERTIFICATE_CONFIG` is set). That gate is temporary and Python-only, so it isn't copied here. On GKE, both libraries bind ID tokens by default. #14559 adds the per-target `DISABLE_BOUND_ID_TOKEN` opt-out. ## Related - #14556 (HTTP/JSON mTLS fix, merged) enables mTLS over HTTP/JSON transports. - #14559 (`DISABLE_BOUND_ID_TOKEN`) is the per-target ID-token opt-out. ## Tests ### Unit tests - `MtlsUtilsTest`: - bundle present, absent, a directory, or empty; - `USE_CLIENT_CERTIFICATE=false`; - a default config without a workload section (ECP) blocks the bundle; - an explicit config takes precedence; - `hasCertificateConfiguration` / `getGkeCredentialBundlePath`. - `X509ProviderTest`: - transport provider with cert-first and key-first bundles; - an explicit config, or an override path, takes precedence; - unavailable when there is no bundle; - the public constructor ignores the bundle (WIF). - `AgentIdentityUtilsTest`: - implicit discovery with zero sleeps; - the cached credential stays bound; - opt-outs, a default gcloud config, and a non-agent cert all leave the token unbound; - an empty or absent bundle returns null without polling; - explicit true finds the bundle, never polls for it, and prefers it over the Cloud Run files; - fallback to the cache after the bundle is deleted, and no fallback once a certificate config has appeared (implicit and explicit paths). Full `oauth2_http` suite: 1089 tests, 0 failures. `fmt` is clean. ### Live test on GKE - **Cluster:** a GKE cluster with agent identity enabled. - **Pods:** the test pods get the agent identity credential bundle at `/var/run/secrets/workload-spiffe-credentials/x509.credential-bundle.private-key.pem`. - **Image:** built from this PR's jars merged with #14556, which is already on the base branch and is required for HTTP/JSON mTLS. It uses ADC with default settings and no client options. - **Details:** cluster setup, manifests and full logs are in the internal links below. **Checks:** - **GCS over raw HTTP:** read through `storage.mtls.googleapis.com` with the transport certificate. The same token on plain `storage.googleapis.com` gets 401, which proves the token is bound. - **GAX Resource Manager client:** `getProject` over gRPC and HTTP/JSON. - **ID tokens:** sent to an agent-to-agent receiver pod. It accepts only bound tokens over mTLS whose `cnf` matches the client certificate, and only unbound tokens over plain HTTP. | Scenario | Token | GAX resolved endpoint | GAX gRPC / HTTP-JSON | GCS mTLS / plain | ID token mTLS / plain | |---|---|---|---|---|---| | Defaults | Bound; `cnf` = bundle leaf = transport cert | `cloudresourcemanager.mtls.googleapis.com` | ✅ / ✅ | 200 / **401** | **200** / 401 | | `GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false` | Unbound | mTLS endpoint | ✅ / ✅ | 200 / 200 | 401 / **200** | | `GOOGLE_API_USE_CLIENT_CERTIFICATE=false` | Unbound | plain endpoint | ✅ / ✅ | 200 / 200 | 401 / **200** | | `GOOGLE_API_USE_CLIENT_CERTIFICATE=true` | Bound (bundle) | mTLS endpoint | ✅ / ✅ | 200 / **401** | **200** / 401 | | Pod without agent identity | Unbound, no mTLS | plain endpoint | authenticated / authenticated | — / authenticated | n/a | **Timing:** the first token fetch took about 0.5–1s in every scenario. A pod without the bundle has no polling delay. **Internal links (Googlers only):** [setup](https://paste.googleplex.com/5635555912712192) · [manifests](https://paste.googleplex.com/6258309762514944) · [harness](https://paste.googleplex.com/4882197073494016) · [build/run](https://paste.googleplex.com/5942061774274560) · [results](https://paste.googleplex.com/5072605959290880) **Out of scope for this PR (tracked separately):** - **Leaf-only keystore:** `X509Provider`'s keystore holds only the leaf certificate, through google-http-client `SecurityUtils.createMtlsKeyStore`. Google APIs over `*.mtls.googleapis.com` are unaffected. Agent-to-agent mTLS against a peer that trusts only the SPIFFE root fails unless the caller presents the full chain.

gemini-code-assist Bot reviewed Sep 30, 2026

View reviewed changes

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java

Comment thread google-auth-library-java/oauth2_http/java/com/google/auth/mtls/MtlsUtils.java

macastelaz mentioned this pull request Oct 1, 2026

feat(gax): support transparent retries during mTLS certificate rotations #13995

Merged

macastelaz force-pushed the fix-conscrypt-tmf-13995 branch from c6fcb75 to bc52d23 Compare October 6, 2026 13:49

macastelaz changed the title ~~fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext [blocked on #13995]~~ fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext Oct 6, 2026

macastelaz marked this pull request as ready for review October 6, 2026 13:53

macastelaz requested review from a team as code owners October 6, 2026 13:53

macastelaz requested a review from lqiu96 October 6, 2026 13:54

macastelaz added 2 commits October 6, 2026 17:08

macastelaz force-pushed the fix-conscrypt-tmf-13995 branch from 7289240 to d54e134 Compare October 6, 2026 17:08

lqiu96 reviewed Oct 7, 2026

View reviewed changes

Comment thread ...src/test/java/com/google/api/gax/httpjson/InstantiatingHttpJsonChannelProviderTls13Test.java

lqiu96 reviewed Oct 7, 2026

View reviewed changes

lqiu96 approved these changes Oct 7, 2026

View reviewed changes

macastelaz mentioned this pull request Oct 7, 2026

feat(auth): support GKE agent identity credential bundle for bound tokens and mTLS #14595

Merged

docs(gax-httpjson): clarify Conscrypt mTLS comment and Tls13 test tim…

e19b356

…eout

macastelaz merged commit cf211ea into googleapis:agentic-identities-bound-token Oct 7, 2026
223 of 260 checks passed

macastelaz mentioned this pull request Oct 9, 2026

feat(auth): add DISABLE_BOUND_ID_TOKEN option to opt out of certificate-bound ID tokens #14559

Merged

Navigation Menu

Repository navigation

fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext - #14556

fix(gax-httpjson): use Conscrypt TrustManagerFactory for mTLS SSLContext#14556
macastelaz merged 4 commits into
googleapis:agentic-identities-bound-tokenfrom
macastelaz:fix-conscrypt-tmf-13995

macastelaz commented Sep 30, 2026 •

edited

Loading

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

Uh oh!

Uh oh!

lqiu96 Oct 7, 2026

Uh oh!

macastelaz Oct 7, 2026

Uh oh!

Uh oh!

lqiu96 Oct 7, 2026 •

edited

Loading

Uh oh!

macastelaz Oct 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

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

Conversation

macastelaz commented Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Testing

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

lqiu96 Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

macastelaz Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lqiu96 Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macastelaz Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

macastelaz commented Sep 30, 2026 •

edited

Loading

lqiu96 Oct 7, 2026 •

edited

Loading