SonarAnalysis prepare task "Unable to verify the first certificate"

I’m seeing this issue with my ADO (scanners are using java 11) on SQ version 9.9.8, Java 17, Windows + SQL Server 2022. I migrated this environment from another domain running on lower version of Windows + SQL Server. Upgrading SQ to latest LTA is not an option right now.

I’ve imported the Root CA cert to the JVM in both PEM and DER formats just to be safe. I’ve tried everything else mentioned here (NODE_EXTRA_CA_CERTS, installing the cert to the root store, etc) and still the same issue.

The mentioned solution by sonarsource/stackoverflow was to download the intermediate cert from SQB via openSSL, however the command is returning the same error as ADO “Unable to verify the first certificate”, here is part of the output (removed cert info). Any help would be appreciated, this is exhausting.

NODE_TLS_REJECT_UNAUTHORIZED=0 fixes the problem, but it isn’t a very good solution.

...
...
-----END CERTIFICATE-----
...
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2038 bytes and written 412 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
read:errno=104
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
...
...

Hey @jesmersoy

So this was all working before, and the issue appeared after migration?

If you’re facing this issue in the SonarQubePrepare task, you can ignore Java for now and focus only on the NodeJS stack.

Where are you setting NODE_EXTRA_CA_CERTS? It should not be on the infrastructure where you’re hosting the SonarQube server but instead on your Azure DevOps agents (either at a system level or one-off in the Variables section of your pipeline configuration). Maybe that’s what you’re doing, but I want to make sure!

The mentioned solution by sonarsource/stackoverflow was to download the intermediate cert from SQB via openSSL, however the command is returning the same error as ADO “Unable to verify the first certificate”, here is part of the output (removed cert info). Any help would be appreciated, this is exhausting.

While usually, passing the certs to NODE_EXTRA_CA_CERTS is all that is needed, if openSSL itself is failing, then this smells like an issue with how your certs are configured on your SonarQube server (well, more accurately, whatever is serving it over HTTPS, like nginx or apache)

I think these resources are all useful:

What are you using to serve your SonarQube Server over HTTPS? Nginx? Apache? IIS? Something else?

“So this was all working before, and the issue appeared after migration?”

Yes correct, this issue has to do with new CA we have in new domain.

“If you’re facing this issue in the SonarQubePrepare task, you can ignore Java for now and focus only on the NodeJS stack.”

Can you clarify what you mean by ignore Java, you are saying this is definitely a nodejs install/config issue? I’ve been focusing on jre/jdk cacerts and importing certs in diff formats to no avail, thinking this is JVM related. Strangely, I am able to ‘SonarExecuteAnalysys’ in the new env with no issues, the prepare is failing.

“Where are you setting NODE_EXTRA_CA_CERTS ? It should not be on the infrastructure where you’re hosting the SonarQube server but instead on your Azure DevOps agents (either at a system level or one-off in the Variables section of your pipeline configuration). Maybe that’s what you’re doing, but I want to make sure!”

This is all configured on the ADO build agent server, not SonarQube. I set the system enviroment var NODE_EXTRA_CA_CERTS=RootCAcert.crt (does this cert need to to be in a specific format?)

“While usually, passing the certs to NODE_EXTRA_CA_CERTS is all that is needed, if openSSL itself is failing, then this smells like an issue with how your certs are configured on your SonarQube server (well, more accurately, whatever is serving it over HTTPS, like nginx or apache)”

“What are you using to serve your SonarQube Server over HTTPS? Nginx? Apache? IIS? Something else?”

I was thinking issue is on SQ Server as well, like something to do with intermediate certificate issuing? Our SQ server is configured with SAML + https, using IIS URL Rewriter as reverse proxy. It is authenticating our MS AAD users no issues.

I have not tried setting the NODE_EXTRA_CA_CERTS env var to intermediate cert as I am still trying to obtain it. I’ve raised a ticket with our network engineers but am troubleshooting in the meantime.

The SonarQubePrepare task is written purely in NodeJS. SonarQubeAnalyze uses Java. I guess your JVM certs are working perfectly :smiley:

When set, the well known “root” CAs (like VeriSign) will be extended with the extra certificates in file . The file should consist of one or more trusted certificates in PEM format.

A .crt file is often the same as a .pem file

It seems very likely that your web server is not serving the intermediate cert.

After obtaining an updated root certificate and renaming it with .pem only did it pass the prepare task.

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