Hello All,
I am facing same issue from Azure DevOps pipeline,
##[error][SQ] API GET ‘/api/server/version’ failed, error was: {“code”:“CERT_HAS_EXPIRED”}
Does anyone found the resolution for this? This is a huge blocker for us.
Any help is appreciated.
Thanks
Hi all,
We have just started encountering the same issue in a number of azure devops pipelines running on a mix of windows and linux agents and this is stopping us from running sonarqube.
Its consistently failing on “- task: SonarQubePrepare@4” and the error is “##[error][SQ] API GET ‘/api/server/version’ failed, error was: {“code”:“CERT_HAS_EXPIRED”}”.
We added some tests into the pipeline to verify the certificate chain using openssl and curl both of which come back without error, we also made an https request to the URL in question and it returns without error.
So given this actually works under our test scenario but not using the task we are a little stumped about how to resolve? Cant see the source control for the task online so hard to troubleshoot what its doing under the hood.
Our servers are configured using letsencrypt certificates and a change was made to their production root certificates on september 30th, havent seen anything from our testing to indicate its a cause but will keep in mind in case there is some caching going on with the old root → DST Root CA X3 Expiration (September 2021) - Let's Encrypt
Exactly same situation - our own Sonarqube installation + Lets Encrypt certificates + Azure DevOps agents. Yesterday SonarqubePrepare steps started failing with the same error. Doing curl locally or from the Azure DevOps agent to our managed SonarQube endpoints works fine.
Hi there
We’re currently investigating that.
Thanks.
same problem here. waiting for your answer 
Hello everybody!
We have been able to confirm that the issue is isolated to the Extension for Azure DevOps which uses NodeJS to make some web requests. When making these requests against a SonarQube server using a LetsEncrypt certificate, it fails as a result of the DST Root CA X3 Expiration
This affects the:
So why are these tasks failing?
The version used to execute the task is NodeJS 6, probably owing to the version of microsoft/azure-pipelines-task-lib being used in the task which prefers NodeJS 6 as the task runtime.
NodeJS 6 uses OpenSSL 1.0.2. Read the following about what this means:
Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.
Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.
OpenSSL 1.1.0 fixes this which began to be used in NodeJS 10.
To our knowledge, there is no way to force the task to use NodeJS 10 without an update to our extension. We are investigating the best path forward and will keep you updated.
In the meantime, OpenSSL mentions one workaround that might be available to you:
Workaround 3 (on the servers that 1.0.2 clients connect to)
Configure the server to use the alternative certificate chain which can be requested from Let’s Encrypt with most up-to-date ACME protocol clients. This chain does not contain the ISRG Root X1 cross-signed by the soon to be expired DST Root CA X3 and thus any OpenSSL 1.0.2 clients will not be misled by this expired path.
The downside is that the servers will be seen as using an untrusted root certificate by some older Android clients because these clients do not contain the self-signed ISRG Root X1 certificate in their trust stores.
As mentioned, we’ll keep you updated as we figure out how to move forwards.
Same problem here, eagerly awaiting a fix!
Appreciate if you can elaborate more on how to implement the workaround?
The server you mentioned is our hosted Sonarqube?
We are on Let’s Encrypt, do it mean force renewal of the SSL would solve the issue?
I tried a renewal, it didn’t fix the issue. Our current chain is
ISRG Root X1 → R3 → our certificate
Hi @Colin
here is how to fix your plugin with a minimal impact: Offer way to write tasks that depend on Node 10 LTS · Issue #1850 · microsoft/azure-pipelines-agent · GitHub
users on an ubuntu-latest build agents may define this environment variable for their builds as a work around:
variables:
- name: NODE_OPTIONS
value: --use-openssl-ca
Work fine for me. do we have a same kind of workaround for windows agents ?
Hey all.
An important PR has been merged and a new version of the extension will be released soon (I would very conservatively estimate end-of-day)
Hey all (again),
v4.23 of the Extension for Azure DevOps has been released and should start trickling to your agents soon. You will see this version (v4.23.0) in the Prepare Analysis step once the update has happened.
Let us know that the issue is resolved!
Our issues have been resolved thanks alot 
@Colin I can already see the new version of the extensions in the organization settings, although when I start a new build, the Agent still downloads the 4.22 version of the task 
Any idea on that? Just wait?
I’ll buy a beer for anybody who can figure out how to force azure devops extensions to update — in my many years of using the platform, I’ve never been able to sort it out! I think it checks at a regular interval for updates.
Thanks for quick reaction. One version 4.23 available, task work fine for me. 
Didn’t have a chance to try it before the release propagated, but you could maybe try deleting the SonarQube folders under agent/_work/_tasks on self-hosted agents to force a re-download vs. looking to the cache…? Just a thought.