Scala CLI doesn't work with custom https certificates

[tgodzik]

Version(s)
1.0.0-RC2

Describe the bug
This was reported on Scala Days and is a problem within some corporate environments

The error being shown is the same when Scala version is missing.

To Reproduce
Not sure, we need to set something up.

Expected behaviour
Scala CLI works properly

CC @romanowski

[michaelpigg]

I was able to work around the issue with scala-cli -Djavax.net.ssl.trustStore=cacerts where cacerts contains the custom certificate that needs to be trusted.

[tgodzik]

@romanowski can you ask the user that reported it to test it out?

[michaelpigg]

@tgodzik I am the reporter.

[michaelpigg]

Trying to open a 2.13 repl on Java 11 using the command scala-cli -S 2.13.0 -j 11 gives me the error

Error: java.lang.Exception: java.lang.Exception: Error while getting https://github.com/coursier/jvm-index/raw/master/index.json: download error: Caught javax.net.ssl.SSLHandshakeException (PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target) while downloading https://github.com/coursier/jvm-index/raw/master/index.json

Adding -Djavax.net.ssl.trustStore=cacerts does not help in this case.

[dxxvi]

-Djavax.net.ssl.trustStore=cacerts works for me.

By the way, is it possible to tell scala-cli to use the jdk which is at a particular folder on my machine? I couldn't find that at https://scala-cli.virtuslab.org/docs/overview

[lwronski]

@dxxvi, If you have Java 17 or a newer version already installed and available on the PATH, scala-cli will automatically detect and use it without the need for any additional downloads. This is because Java 17 is the minimum required version for running the compiler server 'bloop' that scala-cli relies on internally.

[lwronski]

Trying to open a 2.13 repl on Java 11 using the command scala-cli -S 2.13.0 -j 11 gives me the error

Error: java.lang.Exception: java.lang.Exception: Error while getting https://github.com/coursier/jvm-index/raw/master/index.json: download error: Caught javax.net.ssl.SSLHandshakeException (PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target) while downloading https://github.com/coursier/jvm-index/raw/master/index.json

Adding -Djavax.net.ssl.trustStore=cacerts does not help in this case.

@michaelpigg Did you try running scala-cli in this way? JVM options should be specified as the first argument if you want to pass them to scala-cli itself rather than to your project.

scala-cli -Djavax.net.ssl.trustStore=cacerts -S 2.13.0 -j 11

[lwronski]

Hi, I'd like to provide an updated summary on this issue, as there are newer and more user-friendly ways to set JVM properties in scala-cli.

1. Direct Setting with -D Prefix: You can set JVM properties directly by prefixing them with -D before any scala-cli command or parameter.

scala-cli -Djavax.net.ssl.trustStore=cacerts -S 2.13.0 -j 11

2. Using .scala-jvmopts file: By creating a .scala-jvmopts file in your current working directory, the properties from this file will be automatically loaded into scala-cli.

$ cat .scala-jvmopts
-Dfoo1=bar1 
-Dfoo2=bar2
$ scala-cli run ...

3. Using the config command: This method allows you to globally set Java properties for scala-cli:

scala-cli config java.properties Djavax.net.ssl.trustStore=cacerts Dfoo=bar2

You can find more details here in our documentation

[lwronski]

I'm closing this issue as there are multiple ways to set Java properties already in scala-cli. I'm not convinced that scala-cli should add the Djavax.net.ssl.trustStore=cacerts property by default. Users should set it manually to prevent unexpected behavior.

[smarter]

I'm not convinced that scala-cli should add the Djavax.net.ssl.trustStore=cacerts property by default.

As things stand, I disagree. I just ran into this and figuring out how to set this setting took me a while (googling scala-cli javax.net.ssl.SSLHandshakeException did not turn up this issue). As scala-cli is slated to become the default runner for scala very soon (scala/scala3#20098), I think it's important to not cause regressions compared to the existing shell script.

[Gedochao]

I'm not convinced that scala-cli should add the Djavax.net.ssl.trustStore=cacerts property by default. Users should set it manually to prevent unexpected behavior.

Generally speaking, I'd stick to this answer. I do not think we should set this by default.

As scala-cli is slated to become the default runner for scala very soon (scala/scala3#20098), I think it's important to not cause regressions compared to the existing shell script.

I wouldn't tie this problem to Scala CLI becoming the new runner at this point. There has been plenty of time for users to test out the new runner via the experimental scala installation. The old scala runner is considered a legacy tool at this point, so I wouldn't consider expected Scala CLI behaviour as a regression.

I just ran into this and figuring out how to set this setting took me a while (googling scala-cli javax.net.ssl.SSLHandshakeException did not turn up this issue).

That being said, we should have a meaningful error message for this, perhaps suggesting -Djavax.net.ssl.trustStore=cacerts, rather than throwing a cryptic javax.net.ssl.SSLHandshakeException.
Recovering from the error with a proper message should be considered the requirement for this ticket.

@smarter can you share the stacktrace you're getting on your environment when the option isn't being passed?
I've yet to figure out how to reproduce this exact problem, so that we can log a solution suggestion.

[smarter]

I'm not convinced that scala-cli should add the Djavax.net.ssl.trustStore=cacerts property by default. Users should set it manually to prevent unexpected behavior.
Generally speaking, I'd stick to this answer. I do not think we should set this by default.

To me it seems the unexpected behavior is having an application not respect any system-wide certificate store.

can you share the stacktrace you're getting on your environment when the option isn't being passed?

I'd like to but no stacktrace is displayed, just the exception message. Maybe there's a flag for forcing graal-native to print stack traces here?

[smarter]

Would it possible to maintain a list of the hostnames that scala-cli tries to access? That way enterprises could consider whitelisting them too.