Find Out What Keystore the JVM Is Using

1. Overview

When working with Java applications that require SSL/TLS connections or certificate management, we frequently have to import certificates into the JVM‘s keystore. However, obtaining the exact keystore file can be difficult, especially when using different operating systems and Java installations.

In this tutorial, we’ll examine multiple approaches to determine which keystore our JVM is utilising.

2. Using the java_home Environment Variable

The JAVA_HOME environment option provides the simplest way to locate the JVM keystore. The Java installer sets this environment variable to refer to the root directory of the Java Development Kit (JDK) or Java Runtime Environment. Furthermore, because the JVM’s default truststore, cacerts, is always in a standard relative path from the Java installation directory, we can rapidly generate the full path to the keystore with JAVA_HOME:

$ echo %JAVA_HOME%\lib\security\cacerts

In this example, the JAVA_HOME environment variable refers to the directory where Java is installed. The cacerts file, the JVM’s default truststore, is located in the lib/security subfolder of this installation path.

Finally, this method presupposes that the JAVA_HOME environment variable is specified correctly. Although the variable is not already set, we can either set it or use one of the other techniques described below. Furthermore, the executing program may be utilising a different Java installation than what JAVA_HOME links to, particularly on systems with several Java versions installed.

3. Finding the User-Specific Keystore

When we run the keytool without specifying a keystore location, Java generates or uses a keystore in the user’s home directory. This user-specific keystore is distinct from the system’s cacerts file and has a different purpose.

Furthermore, the system cacerts contain trusted Certificate Authority (CA) certificates required to validate SSL/TLS connections from remote servers. Additionally, the user keystore normally contains personal private keys and certificates that identify the user or the application:

$ echo %USERPROFILE%\.keystore

In this example, the keystore is user-specific and distinct from the system-wide cacerts file. We typically use it to store personal keys and certificates rather than trusted CA certificates. Additionally, we may not know about this default location and might wonder where the keytool stores keys when we don’t supply a keystore.

4. Using Java System Properties

The keystore location can be determined programmatically using Java system characteristics. This method is dependable and adaptable, particularly for industrial applications and automated systems.

Additionally, unlike environment variables, which can change between shell sessions or user contexts, Java system attributes are inherent in the running JVM instance. These instances always reflect the current configuration:

class KeystoreLocatorIntegrationTest {
    private static final Logger logger = LoggerFactory.getLogger(KeystoreLocatorIntegrationTest.class);
    
    @Test
    void givenJavaInstallation_whenUsingSystemProperties_thenKeystoreLocationFound() {
        String javaHome = System.getProperty("java.home");
        String separator = System.getProperty("file.separator");
        
        String cacertsPath = javaHome + separator + "lib" + separator 
          + "security" + separator + "cacerts";
        
        assertNotNull(javaHome);
        logger.info("Java Home: {}", javaHome);
        logger.info("Expected cacerts location: {}", cacertsPath);
        
        File cacertsFile = new File(cacertsPath);
        if (cacertsFile.exists()) {
            logger.info("Cacerts file exists: YES");
            logger.info("Absolute path: {}", cacertsFile.getAbsolutePath());
            assertTrue(cacertsFile.exists());
        }
        
        String customTrustStore = System.getProperty("javax.net.ssl.trustStore");
        if (customTrustStore != null) {
            logger.info("Custom trustStore is specified: {}", customTrustStore);
        } else {
            logger.info("No custom trustStore specified, using default");
        }
        
        String userHome = System.getProperty("user.home");
        String userKeystore = userHome + separator + ".keystore";
        assertNotNull(userHome);
        logger.info("User keystore location: {}", userKeystore);
    }
}

In this example, we get the Java home directory and construct the cacerts. Also, we check for the custom trustStore property and get the user’s home keystore location path. This method leverages Java system attributes to find the keystore. The java.home property returns the Java installation directory of the currently executing JVM. This may differ from the JAVA_HOME environment variable, particularly on systems with multiple Java installs.

In conclusion, this programmatic approach is very handy when determining the keystore location at runtime. Furthermore, in deployed apps, the environment may differ from our development workstation. It’s also the most dependable way because it uses the same features that the JVM uses to discover the truststore.

5. Conclusion

In this article, we looked at three alternative approaches to figure out which keystore the JVM is using. To discover the system-wide cacerts file, we can utilise the JAVA_HOME environment variable, look in the user’s home directory for the default user keystore, or use Java system attributes to find it programmatically.

Finally, the JAVA_HOME method is rapid and appropriate for manual activities, whereas the programmatic approach is more dependable for runtime determination and works in a variety of situations. Understanding the various keystore locations is critical for effective certificate administration in Java programs.

As always, the code is available over on GitHub.