curl 7.81.0-1ubuntu1.11 fails verifying proper ssl cert w/ subj-alt-name

Status changed to 'Confirmed' because the bug affects multiple users.

This bug is causing breakage in the Lean 4 build cache infrastructure: https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/leantar.20too.20old.20.28lean.20exe.20cache.20get.20not.20working.29/near/376686259

AWS S3 connections through the AWS PHP SDK are failing since upgrading to 1.11 with curl error 60. Downgrading to 1.10 resolves the issue.

I also see the PHP breakage. This took our service partially offline for a few minutes.

We will be reverting this fix until it can be properly investigated. I will prepare emergency updates that will be published today.

This only affects Ubuntu 22.04 because of an issue with the backported patch.

The fix is currently building here:
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

As soon as the riscv64 builds finish, I will be releasing it.

This bug was fixed in the package curl - 7.81.0-1ubuntu1.13

---------------
curl (7.81.0-1ubuntu1.13) jammy-security; urgency=medium

  * SECURITY REGRESSION: broken ssl cert wildcard handling (LP: #2028170)
    - debian/patches/CVE-2023-28321.patch: fix missing line in backport.

 -- Marc Deslauriers <email address hidden> Wed, 19 Jul 2023 12:23:36 -0400

Thanks, Marc - When should we see that package promoted to jammy-updates? It's still showing 1.11 - https://packages.ubuntu.com/jammy/curl

It should appear in -security and get automatically copied to -updates next time the publisher runs, probably within the next half-hour or so.

7.81.0-1ubuntu1.13 fixes the issue for me, thanks for the quick response!

https://ubuntu.com/security/notices/USN-6237-2

Is this fixed for all use cases? I have the 7.81.0-1ubuntu1.13 versions and I'm still getting "no alternative certificate subject name matches target host name" messages for Wordpress beta updates and with a couple of other curl scripts.

Do you have a specific site I can try that doesn't work?

Talking to Wordpress and they think I might have a different issue. If that's not it I'll come back. Sorry about the confusion.

I'm also experiencing this issue now. did update, upgrade, even reboot (this is a dev/staging web server).
Example:

ubuntu@t1:~$ curl -v https://skywaytheatre.com/wp-content/uploads/2023/01/Avatar-flyer-LOCAL-1.png
* Trying 52.37.32.232:443...
* Connected to skywaytheatre.com (52.37.32.232) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.skywaytheatre.com
* start date: Jul 14 10:02:27 2023 GMT
* expire date: Oct 12 10:02:26 2023 GMT
* subjectAltName does not match skywaytheatre.com
* SSL: no alternative certificate subject name matches target host name 'skywaytheatre.com'
* Closing connection 0
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'skywaytheatre.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

ubuntu@t1:~$ apt list curl -a
Listing... Done
curl/jammy-updates,jammy-security,now 7.81.0-1ubuntu1.13 amd64 [installed,automatic]
curl/jammy 7.81.0-1 amd64

What's the output of "dpkg -l | grep curl"?

Thanks for response. Requested output from system with bug (DEV) below:

ubuntu@t1:~$ sudo dpkg -l | grep curl
ii curl 7.81.0-1ubuntu1.13 amd64 command line tool for transferring data with URL syntax
ii libcurl3-gnutls:amd64 7.81.0-1ubuntu1.13 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour)
ii libcurl4:amd64 7.81.0-1ubuntu1.13 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour)
ii php7.3-curl 7.3.33-8+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php7.4-curl 1:7.4.33-1+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php8.0-curl 1:8.0.26-1+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php8.1-curl 8.1.2-1ubuntu2.13 amd64 CURL module for PHP
ii php8.2-curl 8.2.0-3+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ubuntu@t1:~$

Also this is an Amazon EC2 instance running Ubuntu 22.04. It's a dev web server.
The live server which is basically the same image without recent updates and later PHP versions / packages does NOT exhibit this bug.

System with bug:

ubuntu@t1:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
ubuntu@t1:~$

Marc, if there's a way I can give you access to this server thats no problem if it would help. As I mentioned this is just a dev server for a website. Also I just tried update/upgrade again, no go.

ubuntu@t1:~$ sudo apt update
Hit:1 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Get:3 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease [108 kB]
Get:4 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Fetched 337 kB in 1s (427 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
ubuntu@t1:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  gsasl-common libjs-jquery-ui php-twig libgsasl7 libmagickwand-6.q16-6
  libmagickcore-6.q16-6 imagemagick-6-common
Learn more about Ubuntu Pro on AWS at https://ubuntu.com/aws/pro
#
# An OpenSSL vulnerability has recently been fixed with USN-6188-1 & 6119-1:
# CVE-2023-2650: possible DoS translating ASN.1 object identifiers.
# Ensure you have updated the package to its latest version.
#
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
ubuntu@t1:~$ sudo dpkg -l | grep curl
ii curl 7.81.0-1ubuntu1.13 amd64 command line tool for transferring data with URL syntax
ii libcurl3-gnutls:amd64 7.81.0-1ubuntu1.13 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour)
ii libcurl4:amd64 7.81.0-1ubuntu1.13 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour)
ii php7.3-curl 7.3.33-8+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php7.4-curl 1:7.4.33-1+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php8.0-curl 1:8.0.26-1+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ii php8.1-curl 8.1.2-1ubuntu2.13 amd64 CURL module for PHP
ii php8.2-curl 8.2.0-3+ubuntu20.04.1+deb.sury.org+1 amd64 CURL module for PHP
ubuntu@t1:~$

FYI I found that I had an old entry in /etc/hosts for this target domain to the localhost.
In effect it was fetching the (VALID) wildcard cert from my dev server (localhost) instead of reaching out to live server.
The wildcard cert on localhost is valid, though, (t1.skywaytheatre.com), so the error still indicates a bug, however this may be considered a special use case i.e.
CURL error when destination is localhost and cert is wildcard

Thanks