(I’m not sure this is really programming or development, but:)

We need to keep two things distinct here: the trust manager logic, and the data it uses, generically called trust material but usually and defaultly implemented as a truststore — a collection of certificates — which in turn is usually and defaultly implemented as a file using a ‘keystore’ format. (Java uses the KeyStore API, and several related file formats including JKS and PKCS12, to store any combination of ‘self’ certificates each with associated privatekey and/or trusted certificates for others, typically but not necessarily CAs; a keyStore containing only trusted certificates, usually only trusted CA certificates, is a truststore.) It is possible to use the default trust logic with the default truststore, or with a different truststore, or with trust material that isn’t in any store; similarly a non-default logic can be used with any of those three types of data.

The JSSE default truststore can be configured by system properties (javax.net.ssl.trustStore*) but if not it is the file accessed by name jssecacerts if that exists (which is rare) and otherwise cacerts (either) in the directory lib/security relative to the JRE; that much has never changed. However, where a JRE is located has varied and changed quite a bit.

Through Java 8, Sun-then-Oracle provided two different packages: a runtime-only JRE and a ‘full’ JDK. The former would typically install to a standardized location like Program Files [(x86)]Javajre-%version% on Windows or /usr/java/jre-$version on Unix, but you might choose to put it elsewhere. The latter would similarly go to standardized or chosen location, but it would contain the JRE in a subdirectory like jdk-$version/jre. Thus the location for your cacerts file might be $JRE/lib/security or $JDK/jre/lib/security. Starting in Java 9 Oracle changed to supply only a full package that functions both as JDK AND JRE with no subdirectory, so the location is just $JAVA/lib/security.

However other builders could package this differently; originally this was only large Linux distros, which named and located the Java files according to their preferred filesystem layout, but now it includes nearly a dozen ‘independent’ builders who may follow the Oracle practice, a Linux or Unix practice, or leave it up to the person doing the install.

But in all cases system property java.home is the JRE directory (the one containing bin/java) and can be used to find the default truststore location — that’s exactly what the JSSE (or related) code does.

For Sun/Oracle packages, cacerts is simply a keystore file containing their curated set of certs. Other packagers may do the same, but may use something different. In particular all Linux distros I’ve used (not a lot) make the JRE’s cacerts a symlink outside of the Java subtree to a system-dependent location used as the truststore for all kinds of software — not just Java but also openssl (or a fork), NSS (and Firefox/Thunderbird), gnutls, tools like curl and wget, browsers, mail programs, some code-verification tools, and maybe more. This is often controlled by a package named something like ca-certificates or ca-certs and its contents may vary; starting from the Mozilla set is fairly common but not universal, then the various maintainers and packagers may ‘improve’ it, and (like a Java-private file) it may be subsequently modified by the admin(s) of a particular system, business or organization.
Do you consider this ‘bundled’ or not?

One thing that might help you is that if using an Oracle package for 8u120 up all the original (package-supplied) entries in cacerts have aliases ending in [jdk]. If you find any aliases without that suffix you know they were added ‘locally’. But someone doing a local add could misleadingly use that suffix, and there’s no indication of a local delete.

I believe the location of the cacerts file has changed between different JDKs?

As above, the location has changed a little between versions, and varied a lot for different systems or packagers in the same version, but java.home always finds it.

I believe the store type of the cacarts file has changed between different JDKs?
I believe the password of the cacerts file has changed between different JDKs ?

For Oracle packages of Java 18 up cacerts has changed to a PKCS12 with NO password (so yes the doc page is out-of-date). This may or may not be followed by other packagers. All earlier Sun/Oracle packages were JKS with password changeit — but certs (only, not keys) in a JKS can be read without supplying any password, see the javadoc for KeyStore.load.

Taking a step back. The task is to get hold of the JDK’s bundled curated set of CA certs. However, the underlying goal is really for the application to be using just some kind of curated set of CA certs, similar to what a browser does. It doesn’t necessarily need to be the set defined by the JDK. By “curated” we mean that there is a thoughtful ongoing process as to which CA certs is included in the set and that this process is managed by a trustworthy organization.

Getting hold of the JDK’s unmodified cacerts file is near impossible in Java. This is what the JDK 21 documentation has to say about the cacerts file:

cacerts Certificates File

A certificates file named cacerts resides in the security properties directory:

   Linux and macOS: JAVA_HOME/lib/security

   Windows: JAVA_HOMElibsecurity

The cacerts file represents a system-wide keystore with CA certificates. System administrators can configure and manage that file with the keytool command by specifying jks as the keystore type. The cacerts keystore file ships with a default set of root CA certificates. For Linux, macOS, and Windows, you can list the default certificates with the following command:

   keytool -list -cacerts

The initial password of the cacerts keystore file is changeit. System administrators should change that password and the default access permission of that file upon installing the SDK.

Note:

It is important to verify your cacerts file. Because you trust the CAs in the cacerts file as entities for signing and issuing certificates to other entities, you must manage the cacerts file carefully. The cacerts file should contain only certificates of the CAs you trust. It is your responsibility to verify the trusted root CA certificates bundled in the cacerts file and make your own trust decisions.

To remove an untrusted CA certificate from the cacerts file, use the -delete option of the keytool command. You can find the cacerts file in the JDK’s $JAVA_HOME/lib/security directory. Contact your system administrator if you don’t have permission to edit this file.

This seems like bad advice: Changing the content of the JDK installation shouldn’t be done. It should be treated as immutable, IMHO. Also, I think the “changeit” password comment is no longer true.

Bottom line is that – if someone took this advice – that a Java application cannot be sure what cacerts file it uses or if it can even read the certs in the file.

Of course, in these more modern days with containers and all, I can be pretty certain that my application runs atop of an unmodified JDK/JRE installation and I can therefore confidently process the cacerts.

But going forward I would hope that the JDK would provide a way to get hold of the unmodified bundled CA set. I would also hope that they would stop encouraging making changes to a JDK/JRE installation tree … post installation. Even if nobody cares anymore.

Finally, another option for an application would be to bundle someone else’s curated set of CA certs, for example Mozilla CA certs set.