Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

javax.net.ssl TLS configuration does not work in native mode #46368

Closed
ppalaga opened this issue Feb 19, 2025 · 4 comments · Fixed by #46379
Closed

javax.net.ssl TLS configuration does not work in native mode #46368

ppalaga opened this issue Feb 19, 2025 · 4 comments · Fixed by #46379
Labels
area/native-image area/tls TLS Registry related issues and PR kind/bug Something isn't working
Milestone

Comments

@ppalaga
Copy link
Contributor

ppalaga commented Feb 19, 2025

javax.net.ssl as a built-in named TLS configuration was introduced recently. While it works as expected in JVM mode, it does not work in native mode. This is because the lookup of the default cacerts trust store file relies on java.home system property, which is not set at native image runtime. There is no home directory of JRE for native executables and therefore there is also no cacerts file.

When javax.net.ssl is used in native mode, the following exception is thrown:

Caused by: java.lang.IllegalStateException: Could not locate the default Java truststore because the 'java.home' property is not set
	at io.quarkus.tls.runtime.JavaNetSslTlsBucketConfig.defaultTrustStorePath(JavaNetSslTlsBucketConfig.java:89)
	at io.quarkus.tls.runtime.JavaNetSslTlsBucketConfig.trustStore(JavaNetSslTlsBucketConfig.java:48)
	at io.quarkus.tls.runtime.CertificateRecorder.getTrustStore(CertificateRecorder.java:153)
	at io.quarkus.tls.runtime.CertificateRecorder.verifyCertificateConfigInternal(CertificateRecorder.java:117)
	at io.quarkus.tls.runtime.CertificateRecorder.lambda$get$0(CertificateRecorder.java:179)
	at [email protected]/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
...

Related information

GraalVM seems not not to be embedding the cacerts in the native executables by design - https://www.graalvm.org/latest/reference-manual/native-image/dynamic-features/CertificateManagement/
Here is what it does:

During the image building process, the native-image builder captures the host environment’s default TrustStore and embeds it into the native executable.

Possible solution

There seems to be a programmatic way to access the certs from the default trust store via

        TrustManagerFactory tms = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tms.init((KeyStore) null);
        for (TrustManager tm : tms.getTrustManagers()) {
            Log.infof(" tm = %s", tm);
            for (X509Certificate c : ((X509TrustManager) tm).getAcceptedIssuers()) {
                Log.infof(" c = %s", c);
            }
        }

I'd try to make io.quarkus.tls.runtime.CertificateRecorder use those certs for javax.net.ssl unless somebody has a better idea?

Copy link

quarkus-bot bot commented Feb 19, 2025

/cc @radcortez (config)

@ppalaga
Copy link
Contributor Author

ppalaga commented Feb 19, 2025

cc @cescoffier

@ppalaga
Copy link
Contributor Author

ppalaga commented Feb 19, 2025

Here is the idea: #46379

@radcortez radcortez added area/tls TLS Registry related issues and PR kind/bug Something isn't working area/native-image and removed area/config labels Feb 20, 2025
@cescoffier
Copy link
Member

Oh right... that's a great catch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/native-image area/tls TLS Registry related issues and PR kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants