Skip to content

feat: update GoogleUtils#getCertificateTrustStore to first attempt t…#2613

Open
ldetmer wants to merge 18 commits intomainfrom
use-jdk-default-certs
Open

feat: update GoogleUtils#getCertificateTrustStore to first attempt t…#2613
ldetmer wants to merge 18 commits intomainfrom
use-jdk-default-certs

Conversation

@ldetmer
Copy link
Contributor

@ldetmer ldetmer commented Feb 9, 2026

This PR is the first step in stopping maintenance for custom keystore in google-api-java-client see: go/stop-keystore-api-java-client

  1. It updates GoogleUtils.getCertificateTrustStore() to first attempt to load java jdk default certs using logic similar to java's internal TrustStoreManager class before falling back to the custom keystore bundled with google-api-java-client. This is to alleviate issues with the bundled keystore having expired/missing certs

  2. Deprecates GoogleUtils.getCertificateTrustStore()

  3. Deprecates GoogleNetHttpTransport

  4. updates documentation to refer users to NetHttpTransport

Tested using GoogleNetHttpTransport.newTrustedTransport() to make call to storage API.

@ldetmer ldetmer force-pushed the use-jdk-default-certs branch from e20a107 to d1f59c2 Compare February 12, 2026 21:11
@ldetmer ldetmer marked this pull request as ready for review February 12, 2026 21:17
@ldetmer ldetmer requested a review from a team as a code owner February 12, 2026 21:17
}
}

throw new IOException("Unable to load default JDK cacerts file");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this exception is swallowed later without any logging, can we just return null to simplify the logic? A null check is also slightly more performant than a try catch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good call, updated to return null.

I didn't add logging because technically client fails to load default certs the client continues to behave the way it does today, but if you think we should call out that we weren't able to load the certs, let me know and I'll add.

/** Default JDK cacerts file path relative to java.home. */
@VisibleForTesting
static String[] possibleJdkPaths = {
"lib/security/cacerts", // Java 9+
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you get a chance to test against different JDK versions and/or JDK vendors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested locally against 8. 17, 25 - they all used lib/security/cacerts (zulu, oracle)

The CI required me to add jre/lib/security/cacerts, so it seems more like a host env issue, as CI runs zulu but on linux. I removed the invalid comments attributing the different locations to differenet versions of java.

@blakeli0
Copy link
Contributor

The PR title should probably be feat instead of chore.

@ldetmer ldetmer changed the title chore: update GoogleUtils#getCertificateTrustStore to first attempt t… feat: update GoogleUtils#getCertificateTrustStore to first attempt t… Feb 13, 2026
@ldetmer ldetmer requested a review from blakeli0 February 13, 2026 21:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size: m Pull request size is medium.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants