Azure Devops with our own build & deployment agents on our Azure hosted VM’s, SonarQube Enterprise Edition 10.7 running on Azure hosted VM (Windows Server 2019).
Using the latest SonarQube extension (7.0.3) v7 tasks in our builds with ‘Integrate with .NET’ I want to disable JRE auto-provisioning globally. We want to use the installed JRE because this is configured for our own certificates (we use our own CA)
With v6 tasks and ‘Integrate with MSBuild’ the installed JRE is used.
With v7 tasks and using sonar.scanner.skipJreProvisioning=true the installed JRE is used. However we have hundreds of builds and it is no solution to modify every one of these.
Hi there, @droos_rdw and welcome to the community.
There is no global flag to disable JRE provisioning, no.
We are aware of the difficulties with private certificates and are working on a solution for the Scanner for .NET. Unfortunately, I do not have a timeline yet for the solution.
Just to make sure, since you are using the Scanner for .NET, I imagine your certificates are installed in the OS trust store?
Thanks for the update.
Yes on “your certificates are installed in the OS trust store”.
So this is regarding the SonarScanner CLI. It would be nice if an (environment) option could be added for the Scanner for .NET to not use auto-provisioning. The logic for finding and using the installed JRE is working fine.
For the time being I will advise our developers to continue using the v6 tasks (and ignore the deprecated warning)
I want to thank you for your patience on this one. We have the certificates problems lined up as one of the first topics we will tackle after the end-of-year break.
Rest assured we are fully aware this is a blocker for many of you and we will find a way to address it.
Is using On Premises SQ with a self-signed certificate really so unexpected that you never thought about this use case before implementing the new feature?
Is this really a new idea? I usually expect a product to be built with the customer in mind…
We also encountered this issue. After some debugging it looks like the task uses the jre provided by SonarQube itself. Even with all the necessary prerequisites set.
If you want a workaround for now:
Replace the cacerts file in the SonarQube ‘jres’ folder in the JDK archive you are using for your pipeline agents. We’re using Windows, so the location is as follows:
sonarqube-2025.1.0.102418\jres\OpenJDK17U-jre_x64_windows_hotspot_17.0.13_11.zip\jdk-17.0.13+11-jre\lib\security\
We’re using private CA’s which are automatically added to the installed Java keystore, so it was just a matter of copying the modified cacerts to the archive above.
It’s unfortunate that this seems necessary, a simple environment variable or java_home check would have sufficed from SonarQube’s side.
An update from our side. We have worked on replacing our certificate with a certificate derived from an known CA. This has been succesfull but we hit another obstacle. The Prepare Analysis task gives an error: API GET ‘/api/server/version’ failed. Error message: unable to get local issuer certificate
The certificate we use is derived from “Entrust OV TLS Issuing RSA CA 1” which is derived from “SSL.com TLS RSA Root CA 2022”.
The Node16 runtime is embedded within the Microsoft (build)agent as is the Node20 runtime. As a test we renamed the Node16 folder and made an symbolic link from Node16 to the Node20_1 folder after which Prepare Analysis ran succesfull and also the actual Analysis.
As Node16 is deprecated since september 2013 can the dependency on Node16 be changed to Node20_1 for the v7 tasks?
Facilitating private certificates is still appreciated
While I’ll let somebody else decide when we make this change in the extensively, I think you can more gracefully force using the Node20 runner using the AGENT_USE_NODE20_1 environment variable.
On our end adding the runner should be fairly trivial, as versions of Azure DevOps not supporting it can continue to use the NodeJS 16 runner as long as we leave it there. Again, somebody else will make that call.
Thank you @Colin. I did not know about that option. Have tried it in 1 build, it works and will ask the persons maintaining our buildservers to set the variable on VM/OS level.
