CERT_HAS_EXPIRED issue on SonarQube

Is there a way to enforce this at system level for a Windows Server? I have a number of agents installed on a dedicated Windows Server VM and I’d like all pipelines running on those agents to use the new Node.js version without having to go through each project’s YML definition. Unfortunately I can’t find any documentation regarding AGENT_USE_NODE10. Do I just put that as a new Windows environment variable with “true” as value, or am I naïve to think this will work?

Unfortunately changing the chain for the LE certificate is not an option as the process is handled by Sophos UTM and no additional settings can be provided in there (unless I want to start messing with the UTM’s internal scripts… which I don’t).

I am on the same boat. We have multiple build agents on multiple build servers. Changing every build pipeline does not seem practical.
Also, unfortunately changing the Lets Encrypt cert also is not an option for us.
Do we have any other option/workaround to handle this in better way?

We are in desperate need to resolve this issue.

Update : Adding env variable at the server fixed the SQ tasks but broke the other tasks which are dependent on older version of NODE. So this is clearly not a good workaround.

When are you guys planning to push the fix for this issue?

Maybe some sort of chart on the recommendations would be of help.

First, if you are able to fix the certificate chains, then that would fix the issue, regardless of what version of the DevOps extension you have. It will probably also fix a lot of other issues brought about by the expired root certificate.

If the above is not feasible due to infrastructure restrictions or limitations, then the next step depends on what version of the DevOps extension you have.

If on v4.23.0, then you’d only need to make sure that your agent is at 2.144.0 or later because the DevOps extension v4.23.0 requires this. Note that even if you don’t use HTTPS connectivity to the SonarQube server, but your DevOps extension got updated to v4.23.0, you’d still need to ensure that your agent is at 2.144.0 or later. Otherwise, the extension/task will fail.

If on v4.23.1 and using HTTPS, then you’d have to be able to set the environment variable AGENT_USE_NODE10 and make sure that your agent is at 2.144.0 or later. The environment variable is only recognized by agent version 2.144.0 or later. I mentioned that there are inherent risks to this, because when you set the environment variable, all other DevOps extensions will be targeted to use Node10 and those other extensions might not be compatible running with Node10, in which case you’re now gonna be trying to figure out how to fix the other extensions.

If on v4.23.1 and using HTTPS, but you are restricted/limited from setting the environment variable and ensuring your agent is at 2.144.0 or later, then you’re out of luck. Might need to figure out how to downgrade to v4.23.0 or wait for that new MAJOR version that they’re coming up with (which will also require agent 2.144.0 or later anyway).

2 Likes

Hi All

Again apologies for the pain this is causing, I hope you’ve found a solution with the workarounds. Thanks @peter_w for sharing your clarifications. The new version is looking like a few weeks away, we’ll do our best to get it out as soon as we can.

Tom

For us the workarounds are some breathing space. But not on all of our builds. So I really hope the new version will be here soon. Because our company has a LOT of pipelines and the only fix working is the usenode10 var which isn’t the best solution because it has broken some of the pipelines and needs to be deleted on all pipelines again if the new version comes.

Hi @Merlijn_Vermeer

Well to say the least, the new major version will also need a manual actions on all of your pipelines, but this one shall not be temporary compare to the env variable to set.

Hello Everyone,

Do we have any news about this fix?
When should we expect this fix to be released?

Thanks,
Nitish

Hi @neet.neet14

We’re working on it, ETA is sometimes next week.

Mickaël

1 Like

We are running in Azure Devops.
We are running Windows agents.

We’ve updated our cert, and it didn’t fix the issue.
Adding in the node_10 variable allows it to run before failing with another issue.

I’ve had to disable the step for now.

What else can we try?

Hi @SgtWilko

What is this over issue you’re talking about ? Is it related to our extension ?

Mickaël

Hello all here,

Just to let you know that SonarQube extensions now has a new major version (5.0.0)

It has the following features/requirements:

  • Node handler has been bumped to 10, getting rid of this Certificate issue
  • Version 2.144.0 of the build agent is now required to run it, which is a built-in version starting Azure DevOps Server 2019
  • To benefit from this version, you’ll have to bump manually your pipeline to :
  • SonarQubePrepare@5
  • SonarQubeAnalyze@5
  • SonarQubePublish@5

Or if you still have the classic editor, you’ll have to select the 5.* version in the dropdown at the top of the task configuration.

Hope this resolves this issue for most.

Thanks.
Mickaël

2 Likes

Thanks, @mickaelcaro and the Team!
Looks like this new version works fine and there is no cert issue!

1 Like

Hi there,

Since Friday, error came back:

2021-11-04T15:03:01.8954136Z ##[section]Starting: Prepare analysis on SonarQube
2021-11-04T15:03:01.8962967Z =============================================================================
2021-11-04T15:03:01.8963415Z Task : Prepare Analysis Configuration
2021-11-04T15:03:01.8963740Z Description : Prepare SonarQube analysis configuration
2021-11-04T15:03:01.8964076Z Version : 5.0.0
2021-11-04T15:03:01.8964306Z Author : sonarsource
2021-11-04T15:03:01.8964797Z Help : Version: 5.0.0. More Information
2021-11-04T15:03:01.8965467Z =============================================================================
2021-11-04T15:03:02.4554107Z ##[error][SQ] API GET ‘/api/server/version’ failed, error was: {“code”:“CERT_HAS_EXPIRED”}
2021-11-04T15:03:02.4636155Z ##[section]Finishing: Prepare analysis on SonarQube

I upgraded my task to version 5.0, set following env var:

NODE_OPTIONS=–use-openssl-ca

My agent is an ubuntu 20.04

Hi @RomainLEGER

With the 5.0 version, you don’t need this env var anymore. Can you test once more without it ?

Mickaël

I just tried and same issue unfortunately.

Hello there,

Any update about my issue ? Am I the only one with this problem ?

Regards,
Romain

Finaly I resolve my problem. The root cause was website certificate expired.
I also migration tasks to version 5 and remove old env var

Regards,
Romain

Hiya,

Upgrading to v5 of the plugin showed the same issue.
Turns out that just before the SSL cert issue we were almost at the default post size limit of nginx.
During the time that we had the Azure plugin disabled we had breached the max post size and so when we used the work-around it failed with a new error.

Got to love coincidences!!!

1 Like