CERT_HAS_EXPIRED issue on SonarQube

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:

  • Prepare Analysis Configuration task for projects using the standalone scanner
  • Publish Quality Gate Result task

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.