Unable to read truststore error since macOS Sonar Scanner CLI since 7.0.0.4796

Ok I found a solution, most likely the cacerts file was corrupted in some way, so I recreated it by running the commands:

dpkg --purge --force-depends ca-certificates-java
apt install ca-certificates-java

and now the sonar scanner CLI has been executed without errors.
Thanks a lot @Julien_HENRY :slight_smile:

1 Like

Thanks a lot for the feedback! I am glad you managed to solve the issue.

1 Like

Hello,
We’ve had the same certificate problem for about 4 hours now.

11:00:18.289 INFO  EXECUTION FAILURE
11:00:18.291 INFO  Total time: 1.046s
11:00:18.291 ERROR Error during SonarScanner CLI execution
nl.altindag.ssl.exception.GenericKeyStoreException: Unable to read truststore from '/var/jenkins_cacerts/cacerts.jks'
	at org.sonarsource.scanner.lib.internal.http.OkHttpClientFactory.configureSsl(OkHttpClientFactory.java:144)
	at org.sonarsource.scanner.lib.internal.http.OkHttpClientFactory.create(OkHttpClientFactory.java:79)
	at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.init(ScannerHttpClient.java:52)
	at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:142)
	at org.sonarsource.scanner.cli.Main.analyze(Main.java:76)
	at org.sonarsource.scanner.cli.Main.main(Main.java:64)
Caused by: java.io.IOException: BC JKS store is read-only and only supports certificate entries
	at org.bouncycastle.jcajce.provider.keystore.util.JKSKeyStoreSpi.engineLoad(Unknown Source)
	at org.bouncycastle.jcajce.provider.keystore.util.AdaptingKeyStoreSpi.engineLoad(Unknown Source)
	at java.base/java.security.KeyStore.load(KeyStore.java:1473)

We are using the docker image (latest in general). Version 11.2 released this morning includes scanner version 7.0.1.4817.
The problem occurs in our CI (jenkins + kubernetes plugin).
We have gone back to version 11.1.
FYI, this is a private keystore, with the default password changeit. This keystore is used in all our applications. In our CI, it is referenced in the env variable JAVA_TOOL_OPTIONS (-Djavax.net.ssl.trustStore=/var/jenkins_cacerts/cacerts.jks).
Do you need additional information to help diagnose the problem?

Hi @Fabrice_P ,

The error says the store is read only, which should be perfectly fine for us, since we are only attempting to read from the truststore (KeyStore.load). So I am a little puzzled.

This seems to be the same issue as @pdxeng , who ended up recreating a new truststore, but we did not really find the root cause of the issue.

My blind guess would be that the keystore was created with some parameters (or by an old version of keytool) that are supported by the native Java implementation, but not by BouncyCastle. Do you know by chance what was the command used to generate the cacerts? Or maybe could you use Keystore Explorer to inspect the cacerts file and see if it has some non standard attributes?

I will also try to investigate more deeply on my side.

For example, this is what I get on my side on a default Open JDK 21 cacerts, when diaplying “Tools → Properties of the keystore”


(sorry this is in french)

The keystore type is JKS. Is it the same on your side?

I have the same values on my side (Type : JKS and Fournisseur : SUN)
I can’t upload images (uploads to aws are blocked by our proxy)
NB: I’m French too :slight_smile:

@Fabrice_P Can you please run:

keytool -v -list -keystore /var/jenkins_cacerts/cacerts.jks

and check if you have entries that are different than trustedCertEntry

In my case, I have:

Type de fichier de clés : JKS
Fournisseur de fichier de clés : SUN

Votre fichier de clés d'accÚs contient 166 entrées

Nom d'alias : debian:ac_raiz_fnmt-rcm.pem
Date de création : 11 févr. 2025
Type d'entrée : trustedCertEntry
[...]

And all 166 entries are of type trustedCertEntry. I suspect there is something else in your cacerts that is causing the issue (for more technical details, see the issue I reported to BouncyCastle)

(If I could create a keystore reproducing your issue, that would be much simpler to fix it.)

OK, I was finally able to reproduce it.

Your cacerts file is likely to contain a PrivateKeyEntry which is suspicious. As far as I know, the cacerts file should only contain trustedCertEntry

See https://www.baeldung.com/java-keystore-truststore-difference

I don’t know how you ended up having a PrivateKeyEntry in the cacerts, but I think that would be better to simply remove it. You might have to export all certificates, then re-import in a clean new store.

If you need a private key for client authentication, this is usually done by having a separate keystore, and pointing to it using javax.net.ssl.keyStore for Java applications (or sonar.scanner.keystorePath for Sonar Scanners).

You’re right, we have 3 private keys (Type d’entrĂ©e: PrivateKeyEntry) in the jks file.
I’ll manage to create another keystore containing only the trusted certificates for the CI.
Thank you very much for your analysis.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.