Great @Colin
Thanks for holding tight with the problem
Its worked for me as well
Unfortunately this is not that easy, we’re not managing at all those folders, and permissions-wise, not sure that we would be ok.
Maybe at the very end trying reinstalling the extension might do the trick.
Mickaël
Thank you very much everyone. New version 4.23 of the task resolved the issue.
Hi!
We did not encounter the CERT_IS_EXPIRED issue, but our agents were updated today with the 4.23.0 version. Since that update, our builds are failing with ::
##[error]A supported task execution handler was not found. This error usually means the task does not carry an implementation that is compatible with your current operating system.
We are running TFS v16.131.27701.1 on Windows 2016 servers. What further information can I provide?
working for us now too, thanks for the update
…
Task : Prepare Analysis Configuration
Description : Prepare SonarQube analysis configuration
Version : 4.23.0
…
Finishing: Sonarqube prepare analysis
…
We were using v2.131.0 of the TFS agent. When we updated to v2.193.0, the issue was resolved.
2 Likes
Hello
Unfortunately the new version of the Extension for Azure DevOps - v4.23 has caused problems for users running TFS 2017 and TFS 2018 because the required NodeJS version is not available on the default agent. For this reason we will need to rollback the change at 0900CET on the 7th October. The reverted version will be v4.23.1. Once this has been done those people with the LetsEncypt certificate issue will once again see failures if no action is taken, however we have identified a couple of simple workarounds that you can apply now to avoid this:
- For people with build agent version above or equal to 2.144.0, set the AGENT_USE_NODE10 environment variable to true on your build agents — this can be set at an individual pipeline level.
- Regenerate the certificate installed on your SonarQube from LetsEncrypt server to not include the expired certificate in its trust chain. This means requesting a certificate via your ACME client (like certbot to use an alternative chain, specifically --preferred-chain "ISRG Root X1”
If either of these are not possible you can also uninstall and manually re-install the v4.23 extension so that it is not automatically updated to v4.23.1. Documentation for managing extensions can be found here.
If you can apply any of these workarounds before we rollback, you should have no further disruption. We’re really sorry for the inconvenience this has caused.
Tom
2 Likes
I think the v4.23.0 release is good enough and this planned upcoming v4.23.1 is a regression. Wouldn’t it be possible to just post a requirement stating that starting with v4.23.0 onwards, the agent has to be 2.144.0 or above?
v4.23.0 is an upgrade where it starts to use Node10, which is essentially where we want to move forward to. Changing it back on v4.23.1 to use Node6, and relying on an environment variable to retarget Node10 at runtime, seems to be a regression.
Also, by setting the environment variable, we are essentially retargeting all other DevOps extensions that may possibly be using Node6 and who knows if those other extensions may fail when retargeted to Node10.
Hi @peter_w welcome to the community.
Unfortunately we cannot simply do that : Extension is updated automatically on each minor/patch release, and doing that will still fail the build (and even more harshly) of our current TFS 2017 /2018 users. And that’s totally the point of doing this rollback : we still have to provide support for them, and upgrading a build agent to that version on those editions of TFS is not that easy and may cause incompatibility as well.
This new version will be a quick-fix, and we will be addressing that by releasing a new major version of the extension (for which you’ll have to opt-in manually) that will be compatible with agent 2.144.0 and Node10 and onwards.
Hope you’ll understand our position here, this was really not easy to address.
Mickaël
Hi!
This is our environment:
- agent pool: ubuntu-latest
- agent version: v2.193.0
- sonar scanner: v4.23.1
- certificate chain: Let’s Encrypt > R3 > ISRG Root X1
As I understand it, we shouldn’t be affected by this issue, but still it happens.
What can we do to resolve it?
Best Regards
Josef
Hi!
Seems the CERT_HAS_EXPIRED issue is back with the newest release on our build pipeline.
The issue from 1st of October was resolved and seems to be back with latest update of the plugin.
Please let me know if there is a way to resolve the issue.
Best Regards,
Martin
[error][SQ] API GET ‘/api/server/version’ failed, error was: {“code”:“CERT_HAS_EXPIRED”}
Same issue i was facing from last 4-5 hours before.
Please let me know if there is a way to resolve the issue.
Best Regards,
Milan
Hi there,
Please follow the guidelines just 3 posts above here : CERT_HAS_EXPIRED issue on SonarQube - #49
Thanks.
Mickaël
Number 2 already applies to our environment, do we have to perform both actions?
I’ll give it a shot.
No, we’re using MS-hosted agents, hence the “agent pool: ubuntu-latest” above.
Ah, yep, sorry, i overlooked it. So yes i think that the old certificate might still be in the store of those build agent, so you’ll probably need to add that variable (as per the workarounds explained here : Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog)
When will the new major version be released @mickaelcaro ?
Thank you @mickaelcaro, setting the variable AGENT_USE_NODE10 = true works for our environment.
2 Likes
Sorry, we were still using the old cross-signed certificate chain containing DST Root CA X3 because of a configuration issue. We manually fixed the configuration and got a new certificate without DST Root CA X3. We’re running the pipeline now to check if it works.
EDIT: with the fixed configuration and the new certificate chain everything works 
2 Likes