curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it

[mchittineni]

I ran a docker image to install RUN mkdir github-action-runner && cd github-action-runner && curl -O -L https://github.com/actions/runner/releases/download/v2.305.0/actions-runner-linux-x64-2.305.0.tar.gz && tar xzf ./actions-runner-linux-x64-2.305.0.tar.gz && rm ./actions-runner-linux-x64-2.305.0.tar.gz

I expected the following Docker image to get published with a Linuxx64

curl/libcurl version

[curl -V output]

operating system - ubuntu-latest

[bagder]

This is curl working as intended. The server's cert is signed by a CA and that CA's certificate is not in the cert bundle curl uses to verify the cert with.

[mchittineni]

i didn't get that. can you rephrase please.

[bagder]

The entire explanation is what you already wrote in the subject:

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it

read more

[mchittineni]

when i'm trying to run the curl on my local it's working as expected, but when i'm trying to execute the command inside an image, it's throwing me the following error.

[patrick-stephens]

The issue seems to occur for me with curl 7.81.0-1ubuntu1.11 but not curl 7.81.0-1ubuntu1.10.
A working host then triggers the same failure when upgraded.
Using a base image or VM with the 7.81.0-1ubuntu1.11 version fails.

[peterellisjones]

We're seeing the same issue since the recent curl security update on Ubuntu Focal.

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it

The problem is that the certificate is correct! We are getting this error with a valid wildcard SAN that matches the host.

We were able to reproduce the error by

1. Running the curl request on an ubuntu image built yesterday
2. apt-get update && apt-get upgrade -y to update curl to the latest version
3. See that curl now fails with the error

I notice the security update CVE-2023-28321 is related to matching of IDN names. None of the domains in our certificates are IDN names

[patrick-stephens]

@peterellisjones yeah that matches up - using a container or VM base image picks up the latest but I had my existing host working because it had not updated. When I updated it explicitly it then failed in the same way.

#11475 (comment)

[patrick-stephens]

And the certificate is fine across a whole test suite of various OS VMs, only the Ubuntu 22.04 ones are failing for the exact same steps.

In this case it was installing docker but it is the same wildcard certificate issue.

curl -fsSLv "https://download.docker.com/linux/ubuntu/gpg"

The issue seems to be curl=7.81.0-1ubuntu1.11, using the previous version it succeeds.

[bilby91]

I can confirm that we are experiencing the same problem since this morning. Any curl call to a domain that is backed by a SAN fails validation.

[patrick-stephens]

Pinning to the non-security update version seems to resolve it:

apt-get install --allow-downgrades -y curl=7.81.0-1 libcurl4=7.81.0-1

However, not ideal.

[tedmielczarek-fastly]

Related: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2028170

[aflansburg]

I can confirm that we are experiencing the same problem since this morning. Any curl call to a domain that is backed by a SAN fails validation.

Seeing this as root cause of failures on CircleCI pipelines when executing curl inside of runner containers to install the Datadog agent.

[ryanbrainard]

This is curl working as intended. The server's cert is signed by a CA and that CA's certificate is not in the cert bundle curl uses to verify the cert with.

Running with curl 7.81.0

$ curl -v https://api.github.com > /dev/null
...
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
*  start date: Feb 16 00:00:00 2023 GMT
*  expire date: Mar 15 23:59:59 2024 GMT
*  subjectAltName does not match api.github.com
* SSL: no alternative certificate subject name matches target host name 'api.github.com'
...

even though the SAN is there on the cert:

openssl s_client -connect api.github.com:443  </dev/null 2>/dev/null | openssl x509 -noout -text | grep -B 1 DNS
            X509v3 Subject Alternative Name: 
                DNS:*.github.com, DNS:github.com

Downgrading curl:

apt-get install --allow-downgrades -y curl=7.81.0-1 libcurl4=7.81.0-1

and now the SAN is ok:

$ curl -v https://api.github.com > /dev/null
...
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
*  start date: Feb 16 00:00:00 2023 GMT
*  expire date: Mar 15 23:59:59 2024 GMT
*  subjectAltName: host "api.github.com" matched cert's "*.github.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
*  SSL certificate verify ok.
...

[ydixken]

We can confirm this as well. Since this morning docker builds with upgraded curl are failing. Same error as above.

[jacobwoffenden]

https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2028170/comments/8 fix released

[bagder]

So this was Ubuntu patching a security problem with a broken backport of a CVE-2023-28321 patch that broke certificate validation.

This bug never existed in code shipped by the curl project.

[SuperSandro2000]

Cane someone link the commit where the faulty patch was fixed? I can't find it Ubuntus messy infrastructure.

[dfandrich]

See the link posted by @tedmielczarek-fastly and @jacobwoffenden.

[anleib]

patch