SSL Exception

[Thomas Griffith]

Hello. If you have a minute, I've been messing around with REST and trying to grab a JWT from an HTTPS endpoint. The cert chain at the endpoint is...

server cert (acme004.acme.com) --> Acme Subordinate CA --> Acme Root CA

I administer the endpoint server (acme004.acme.com) and TLS is working for browser requests so from the TLS keystore on the server (pfx), I extracted the public certs for Acme Subordinate CA and Acme Root CA and saved them to their own crt files...

AMCE_SUBORDINATE_CA.CRT

Bag Attributes: <No Attributes>
subject=CN = Acme Subordinate CA
issuer=CN = Acme Root CA
-----BEGIN CERTIFICATE-----
NDKDI...blah...blah...
blah...blah...DKEID
-----END CERTIFICATE-----

AMCE_ROOT_CA.CRT

Bag Attributes: <No Attributes>
subject=CN = Acme Root CA
issuer=CN = Acme Root CA
-----BEGIN CERTIFICATE-----
MDDLDO...blah...blah...
blah..blah..ZKDLMCL
-----END CERTIFICATE-----

Then I imported each CRT to cacerts in the JVM....

keytool -import -alias acme_root -file ACME_ROOT_CA.crt -keystore cacerts

keytool -import -alias acme_sub -file ACME_SUBORDINATE_CA.crt -keystore cacerts

But I keep getting...

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I've tried several things but keep getting same exception. Is there something up with the order I uploaded (ROOT then SUBORDINATE)? I originally thought I needed to add only the ROOT crt but that was the same exception. Aksi, both the SUBORDINATE and ROOT are in Trusted Publishers (Windows). Thank you very much for reading.

[Ron McLeod]

I might be able to help, but it is not clear (to me) what you are doing and what you are trying to achieve.

This is what I understand:
  - You want to get a JWT from a (web) server.
  - The server has a certificate for hostname acme004.acme.com, which has been signed by Acme Subordinate C.
  - The certificate for Acme Subordinate C has been signed by Acme Root CA, which is presumably a trusted CA.
  - You are able to connect to the server using a browser, presumably without needing to install any certificates in the browser or the platform where the browser is running.
  - You extracted all the certificates in the certificate chain from the server.
  - You are using these certificates with a Java (client?) application (not sure why), and are seeing a SSLHandshakeException.

Is this correct?  Any more information that you can share?

[Thomas Griffith]

Hey.thanks so much for reading and replying.  Yeah, I think you nailed it. Ultimately I am trying to hit a REST endpoint on that server to get a JSON data respnse. The server is HCL Domino and there is a url on that server to acquire a JWT first. But right now I'm trying all this with a standalone jave executable so trying to get the jvm to trust the cert chain.

[Ron McLeod]

Normally, there should not be any need to have the server certificates packaged with the client.  During the TLS negotiation, the server should send its host certificate along with any intermediate certificates to the client side, and the certificate for the (trusted) top-level CA should already be installed on the client platform.

Is there something special in this case?  Is Acme Root CA a non-public internal enterprise CA?

Can you post a simplified version of your application to demonstrate what you are doing (leave out anything which might be confidential)?

[Thomas Griffith]

Hi. Yeah, it's enterprise only intermediate and root certs which are uploaded. presumably by policy, to the windows trust stores. That's what I can't figure out. I see them in Trusted Publishers via cert mgr on my Windows.

Before I tried to upload the intermediate and root certs to jvm cacerts, I had a different SSL exception. I will restore the original cacerts and post that exception. I can't remember what it was, but something telling me it couldn't find a cert. I'll post my code and the original error when I get back. Thanks so much again.

[Thomas Griffith]

Hi, I restored the original cacerts in the jvm. Just the default cacerts, none of my additions...this is the error...

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

and this is the code...

import java.io.OutputStream;
import java.net.HttpURLConnection;
import java.net.URL;
import java.nio.charset.StandardCharsets;

public class jm7 {
    public static void main(String[] args) {

         try {

			// (Your code goes here) 
			
	        URL url = new URL("https://acme004.acme.com/api/v1/auth");
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setRequestMethod("POST");
            conn.setRequestProperty("Content-Type", "application/json");
            conn.setDoOutput(true);

            String jsonInputString = "{\"username\": \"my_name\", \"password\": \"my_pw\"}";
            try {
                OutputStream os = conn.getOutputStream();
                byte[] input = jsonInputString.getBytes(StandardCharsets.UTF_8);
                os.write(input, 0, input.length);

            // Read the response to get the JWT token
            // (Implementation for reading the response goes here)

      	    } catch (Exception e) {
           	 e.printStackTrace();
      	    }

      } catch(Exception e) {
		e.printStackTrace();
      }


    }
}

[Ron McLeod]

Maybe try making a TLS connection to httpbin.org/anything test endpoint with debug logging enable to get a reference of what a successful connection looks like, and then substitute your URL and see how it differs.

The ran the code below using this command line: java -Djavax.net.debug=ssl,handshake jm7.java
and was able to see a trust chain of:"subject" : "CN=httpbin.org" "issuer"  : "CN=Amazon RSA 2048 M02, O=Amazon, C=US" "subject" : "CN=Amazon RSA 2048 M02, O=Amazon, C=US" "issuer"  : "CN=Amazon Root CA 1, O=Amazon, C=US" "subject" : "CN=Amazon Root CA 1, O=Amazon, C=US" "issuer"  : "CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US" "subject" : "CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US" "issuer"  : "OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US"
I verified that the CA OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US was in the platform's Java truststore:keytool -v -list -cacerts -storepass changeit | grep 'OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US'     Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US [OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]

import java.io.IOException;
import java.io.OutputStream;
import java.net.HttpURLConnection;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.nio.charset.StandardCharsets;

public class jm7 {

    public static void main(String[] args) {
        try {
            URL url = new URI("https://httpbin.org/anything").toURL();
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setRequestMethod("POST");
            conn.setRequestProperty("Content-Type", "application/json");

            conn.setDoOutput(true);
            OutputStream os = conn.getOutputStream();

            String jsonInputString = "{\"username\": \"my_name\", \"password\": \"my_pw\"}";
            byte[] input = jsonInputString.getBytes(StandardCharsets.UTF_8);
            os.write(input, 0, input.length);

            int status = conn.getResponseCode();
            if (status != 200) {
                throw new IOException("Failed to get response from server: status=%d".formatted(status));
            }
            byte[] returned = conn.getInputStream().readAllBytes();
            System.out.println(new String(returned));
        } catch (IOException | URISyntaxException e) {
            e.printStackTrace();
        }

    }
}

[Ron McLeod]

Since it sounds like you are using an enterprise CA which may not be included in the platform's trust store, what you were attempting before to have a custom truststore containing the CA is probably the right move.

I tried the same creating a custom truststore containing the Starfield-G2 CA certificate and then used that truststore rather than the platform's Java truststore, and it did work.

I grabbed the CA cert from here: https://ssl-tools.net/subjects/8bc19e845b981d61cf5469211a68b8e311336d90 and saved the PEM version to the file system.  It looked like this:-----BEGIN CERTIFICATE----- MIIEDzCCAvegAwIBAgIBADANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQw NjI5MTczOTE2WhcNMzQwNjI5MTczOTE2WjBoMQswCQYDVQQGEwJVUzElMCMGA1UE ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMpU3RhcmZp ZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3 DQEBAQUAA4IBDQAwggEIAoIBAQC3Msj+6XGmBIWtDBFk385N78gDGIc/oav7PKaf 8MOh2tTYbitTkPskpD6E8J7oX+zlJ0T1KKY/e97gKvDIr1MvnsoFAZMej2YcOadN +lq2cwQlZut3f+dZxkqZJRRU6ybH838Z1TBwj6+wRir/resp7defqgSHo9T5iaU0 X9tDkYI22WY8sbi5gv2cOj4QyDvvBmVmepsZGD3/cVE8MC5fvj13c7JdBmzDI1aa K4UmkhynArPkPw2vCHmCuDY96pzTNbO8acr1zJ3o/WSNF4Azbl5KXZnJHoe0nRrA 1W4TNSNe35tfPe/W93bC6j67eA0cQmdrBNj41tpvi/JEoAGrAgEDo4HFMIHCMB0G A1UdDgQWBBS/X7fRzt0fhvRbVazc1xDCDqmI5zCBkgYDVR0jBIGKMIGHgBS/X7fR zt0fhvRbVazc1xDCDqmI56FspGowaDELMAkGA1UEBhMCVVMxJTAjBgNVBAoTHFN0 YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAsTKVN0YXJmaWVsZCBD bGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8w DQYJKoZIhvcNAQEFBQADggEBAAWdP4id0ckaVaGsafPzWdqbAYcaT1epoXkJKtv3 L7IezMdeatiDh6GX70k1PncGQVhiv45YuApnP+yz3SFmH8lU+nLMPUxA2IGvd56D eruix/U0F47ZEUD0/CwqTRV/p2JdLiXTAAsgGh1o+Re49L2L7ShZ3U0WixeDyLJl xy16paq8U4Zt3VekyvggQQto8PT7dL5WXXp59fkdheMtlb71cZBDzI0fmgAKhynp VSJYACPq4xJDKVtHCN2MQWplBqjlIapBtJUhlbl90TSrE9atvNziPTnNvT51cKEY WQPJIrSPnNVeKtelttQKbfi3QBFGmh95DmK/D5fs4C8fF5Q= -----END CERTIFICATE-----
Examining it with openssl, it looked correct (Subject Key Identifier and Authority Key Identifier match, CA: TRUE):openssl x509 -text -noout -in starfieldrootcertificateauthority-g2.pem     Certificate:    Data:        Version: 3 (0x2)        Serial Number: 0 (0x0)        Signature Algorithm: sha1WithRSAEncryption        Issuer: C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority        Validity            Not Before: Jun 29 17:39:16 2004 GMT            Not After : Jun 29 17:39:16 2034 GMT        Subject: C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority        Subject Public Key Info:            Public Key Algorithm: rsaEncryption                RSA Public-Key: (2048 bit)                Modulus:                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:                    01:ab                Exponent: 3 (0x3)        X509v3 extensions:            X509v3 Subject Key Identifier:                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7            X509v3 Authority Key Identifier:                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority                serial:00            X509v3 Basic Constraints:                CA:TRUE    Signature Algorithm: sha1WithRSAEncryption         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:         2f:1f:17:94
Then I imported the CA certificate into a new truststore:keytool -importcert -file ./starfieldrootcertificateauthority-g2.pem -keystore ./custom-truststore -storepass "changeit" -noprompt -alias starfieldrootcertificateauthority-g2 Certificate was added to keystore Warning: The input uses the SHA1withRSA signature algorithm which is considered a security risk.
Finally, I ran the app with the custom truststore:java -Djavax.net.ssl.trustStore=custom-truststore -Djavax.net.ssl.trustStorePassword=changeit jm7.java {  "args": {},  "data": "{\"username\": \"my_name\", \"password\": \"my_pw\"}",  "files": {},  "form": {},  "headers": {    "Accept": "*/*",    "Content-Length": "44",    "Content-Type": "application/json",    "Host": "httpbin.org",    "User-Agent": "Java/21.0.2",    "X-Amzn-Trace-Id": "Root=1-66fa0c4f-71f06b2433fe8c9c614e1d52"  },  "json": {    "password": "my_pw",    "username": "my_name"  },  "method": "POST",  "origin": "XXX.XXX.XXX.XXX",  "url": "https://httpbin.org/anything" }

[Ron McLeod]

Here's a quick example of how to use the custom truststore programmatically.  I don't have an easy way to test it, so it may need a bit of tweeking:

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.HttpURLConnection;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.nio.charset.StandardCharsets;
import java.security.KeyManagementException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.cert.CertificateException;

import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;

public class jm7 {

    private static String CUSTOM_TRUSTSTORE_PATH = "custom-truststore";
    private static char[] CUSTOM_TRUSTSTORE_PASS = "changeit".toCharArray();

    static void UseCustomTrustStore() throws CertificateException, KeyStoreException, NoSuchAlgorithmException, KeyManagementException, IOException {
        // Load the CA certificate from the custom truststore
        InputStream tsInputStream = new FileInputStream(CUSTOM_TRUSTSTORE_PATH);
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        ks.load(tsInputStream, CUSTOM_TRUSTSTORE_PASS);

        // Set up TrustManagerFactory using custom truststore
        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init(ks);

        // Initialize the SSLContext with the TrustManager
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, tmf.getTrustManagers(), new java.security.SecureRandom());
        SSLContext.setDefault(sslContext);
    }

    public static void main(String[] args) {
        try {
            UseCustomTrustStore();

            URL url = new URI("https://httpbin.org/anything").toURL();
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setRequestMethod("POST");
            conn.setRequestProperty("Content-Type", "application/json");

            conn.setDoOutput(true);
            OutputStream os = conn.getOutputStream();

            String jsonInputString = "{\"username\": \"my_name\", \"password\": \"my_pw\"}";
            byte[] input = jsonInputString.getBytes(StandardCharsets.UTF_8);
            os.write(input, 0, input.length);

            int status = conn.getResponseCode();
            if (status != 200) {
                throw new IOException("Failed to get response from server: status=%d".formatted(status));
            }
            byte[] returned = conn.getInputStream().readAllBytes();
            System.out.println(new String(returned));
        } catch (IOException | URISyntaxException | CertificateException | KeyStoreException | NoSuchAlgorithmException | KeyManagementException e) {
            e.printStackTrace();
        }
    }
}

[Tim Holloway]

As a general rule, I don't recommend setting up JEE servers to handle SSL themselves. First and foremost because the default SSL port is a "magic" port ID, and Java apps (including JEE servers) cannot listen to that port -- or port 80 -- unless they are running insecurely (as root).

Secondly because obtaining certs and installing them in a Java keystore is a royal pain. The formats required are not the same as you normally get from cert providers for common webservers such as Apache, Nginx and IIs, so you may have to convert them. Then you have to install BOTH the cert and private keys for your cert AND you usually have to install one or more higher-level certs to validate the link to the internal keystore of the server's JVM.

You referenced the "acme" server. If that's  a reference to LetsEncrypt, you'd get a lot better support if you ran Domino through a reverse proxy like Apache or Nginx, and that's especially important since certbot certs require renewal at frequent intervals, so you really don't want to slog through that process manually every few months. And you wouldn't have to run Domino as root.

[Thomas Griffith]

Hello, Ron,

1. the endpoint, httpbin.org/anything, seems to go through, no exceptions, and with no adding trusted public certs.

2. I downloaded the cer file for acme004.acme.com directly from the Edge browser, where it successfully completes TLS handshakes for browser sessions...saved as a cer file, then added that to cacerts. Still throws the same exception for the java program.

3. ran the command line: java -Djavax.net.debug=ssl,handshake jm6 for both endpoints. Both "good" and "bad" endpoint returns their complete chains, as you described, with issuer and subject.

A. The "good" prints out this line...

javax.net.ssl|FINE|01|main|2024-09-30 09:56:01 EDT|null:-1|Consuming ECDH ServerKeyExchange handshake message {....

B. the "bad" throws the Exception...

javax.net.ssl|SEVERE|01|main|2024-09-30 09:56:01 EDT|null:-1|Fatal (CERTIFICATE_UNKNOWN):sun.security.validator.ValidatorException: PKIX path building failed....

so it's still at the same spot, I guess. It's weird because I downloaded the cert directly from the browser and still can't resolve the chain, and that command line java -Djavax does print the chain (subject, issuer)...

[Thomas Griffith]

Hello, Tim. Yeah, I was using the Domino server (intranet) as sort of a proof of concept for REST since it offers a built in JSON data stream (via URL) and trying to access via JWT. Domino also offers a URL to acquire the JWT, which is where I'm having trouble with the https.

[Tim Holloway]

I may have missed it, but just to confirm, JWT stands here for JSON Web Token, right?

For internal use, I'd normally recommend a non-SSL URL, but that's probably silly when obtaining a security token.

The Apache HTTPD and Nginx servers offer JWT support that might make them a better alternative than handling JWT straight from Domino, but I'd have to do something horrible like read the docs to see how that woud work.

[Ron McLeod]

Thomas Griffith wrote:2. I downloaded the cer file for acme004.acme.com directly from the Edge browser, where it successfully completes TLS handshakes for browser sessions...saved as a cer file, then added that to cacerts. Still throws the same exception for the java program.

I guess that indicates that the certificate for the enterprise CA is in the truststore used by the browser, but not in the truststore being used by the Java application.  The Java CA truststore is at: $JAVA_HOME/jre/lib/security/cacerts (on my Linux workstation, that is a link to /etc/pki/java/cacerts).

Thomas Griffith wrote:so it's still at the same spot, I guess. It's weird because I downloaded the cert directly from the browser and still can't resolve the chain, and that command line java -Djavax does print the chain (subject, issuer)...

Have you tried importing the CA certificate into a new truststore and then using that truststore with your Java app - either by specifying the system properties on the command line, or by loading and configuring inside your app?  I provided examples for both.

[Thomas Griffith]

Hey, Ron. I discovered my javac/java command line was using a jvm installed as part of an enterprise Oracle installation, wasn't pointing to my jvm (where I was adding the certs to the cacerts). So I moved my standalone java program (java/class) directly into the bin of my jvm, then ran the following experiments...

1. Do nothing with cacerts

java jm6 - returned the above SSLException: unable to find certification path


2. Add Root CA cert to cacerts

streamed back the login screen html of the target Domino server


3. Restore original cacerts, add the acme004.acme.com cert downloaded from Edge to cacers

streamed back the login screen html of the target Domino server


So I think that explains the SSL issue, but despite sending login credentials, the HTTPURLConnection getting to the Domino JWT endpoint is now being stopped at the server Login screen.

PS Does setting JAVA_HOME to my own JVM override the order of PATH (where Oracle is listed before my JVM)? thank you.

[Tim Holloway]

JAVA_HOME is not a formal or official part of Java. It's a convention used by some, but not all Java apps, and they only support it gets is for either the Java application code or its startup script (for something like TOMCAT) to resolve and use it.

Many complex systems do not use JAVA_HOME, in particular IDEs, which often locate their JVM from a config file.

You'd have to consult the documentation for your product to see where it gets its actual JVM root location. And in special cases, such as some Oracle products, it may well be hard-wired in to ensure that Oracle knows that you're using the JVM that's certified for the product.

That said, plunking in user-supplied certs into a JVM is ill-advised. More properly your keystore should contain the fully tree from user level up to, but not including, one of the universal certifiers supplied from the vendor for the JVM. Usually when you register for a cert, the certifier will include those intermediate certs along with the user cert and key.

[Ron McLeod]

Normally, you would set the JAVA_HOME environment variable to location of the JRE (for example: /usr/lib/jvm/jre-21-openjdk-21.0.2.0.13-1.0.1.el8.x86_64), and then you would add $JAVA_HOME/bin to the PATH (at the beginning in case there are other Java JRE already defined in the PATH).