Ubuntu 26.10 Adds Certificate Revocation Checks to curl

Ubuntu 26.10 Adds Certificate Revocation Checks to curl

📋 Summary: For years, command-line TLS clients have generally verified certificate chains, expiration dates, and hostnames without checking whether a certificate had been revoked. Ubuntu 26.10 changes that for curl by integrating Firefox’s local revocation-data approach through upki. Ubuntu 27.04 is expected to take the next step by integrating the mechanism directly into OpenSSL.

Run the same curl command against the same test server and domain.

On Ubuntu 26.04, the connection succeeds. On Ubuntu 26.10, it fails with:

curl: (60) SSL certificate OpenSSL verify result: certificate revoked (23)

The difference comes from a November 10 announcement by Canonical’s Foundations team. In its demonstration, both systems used unmodified official packages of curl, OpenSSL, and upki. The test server switched from a renewed certificate to a revoked one, and only Ubuntu 26.10 rejected the connection.

For more than two decades, many command-line tools have lacked the browser-style infrastructure needed to keep certificate revocation information current.

Ubuntu is beginning to close that gap.

01. 🔐 Certificate Validation Is Not the Same as Revocation Checking

#

When curl establishes a TLS connection, it uses OpenSSL to validate the server’s certificate chain. The normal validation process checks whether:

1. The certificate chain leads to a trusted root.
2. The certificates are within their validity periods.
3. The server certificate is appropriate for the hostname being accessed.

But a certificate can pass all three checks and still be unsafe.

A Certificate Authority (CA) can revoke a certificate before its expiration date. Common reasons include a compromised private key, an incorrectly issued certificate, or a change in the organization’s security status.

Without revocation checking, a client may continue accepting a certificate that its issuer has already declared invalid.

There are two traditional ways to obtain revocation information, and both have practical drawbacks.

• CRL (Certificate Revocation List): The client downloads a list of revoked certificates. Large CAs can publish lists containing substantial amounts of data, making frequent downloads inefficient.
• OCSP (Online Certificate Status Protocol): The client asks the CA’s server about an individual certificate. This adds a network request, can reveal which sites a user is visiting, and introduces a dependency on the CA’s OCSP responder.

Neither approach is particularly attractive for software that establishes connections frequently or runs in environments with strict privacy and availability requirements.

Browsers had the resources and user base to develop more sophisticated revocation infrastructure. Command-line tools and system libraries largely did not.

The result was an uneven security model: a browser could reject a revoked certificate while an application using the system’s default TLS stack might still accept it.

Changing OpenSSL’s default behavior is also a significant undertaking. OpenSSL is used by thousands of applications and packages. A change to its certificate-validation defaults can affect software across an entire distribution, including applications whose maintainers never anticipated revocation checks.

That compatibility risk helps explain why the gap lasted so long.

02. 🧩 How upki Brings Browser-Style Revocation Data to Linux

#

Firefox developed CRLite to avoid querying remote servers every time it needs to check certificate status.

Instead of asking a CA about each connection, CRLite compresses revocation information into a dataset that can be downloaded and queried locally. The browser can then determine whether a certificate appears in the revocation data without making another network request.

The approach changes the economics of revocation checking:

• No per-connection OCSP request.
• No need to download a massive collection of traditional CRLs for every check.
• No additional connection to a third party that reveals the destination hostname.
• Fast local lookups using cached data.

The upki project makes this type of infrastructure available outside the browser. Developed within the Rustls ecosystem, it provides certificate infrastructure that other TLS implementations can use.

Ubuntu 26.10 connects upki to curl through upki-openssl.

The validation flow works in two stages:

1. curl uses OpenSSL to perform its normal certificate validation.
2. An OpenSSL verification callback provided by upki-openssl checks the server certificate against the locally available revocation dataset.

The important distinction is that upki does not replace OpenSSL’s certificate-chain validation. It adds revocation checking to the existing process.

Why local data makes the difference

#

The underlying idea is not entirely new. The difficult part is distributing enough revocation information to clients without making every connection expensive.

Mozilla’s CRLite system addresses this through compressed, incrementally updated data. upki uses Mozilla’s crlite-clubcard format to work with that information.

Ubuntu does not bundle the full revocation dataset inside the .deb package. Instead, the upki package provides a systemd timer that refreshes the local data in the background every six hours.

That keeps the data reasonably current without adding a network request to each TLS connection.

Installing and activating upki

#

There is an important difference between having the package installed and having a usable revocation dataset.

upki is a Recommends dependency of Ubuntu’s curl package. Standard installations normally include it, but minimal installations and container images built with --no-install-recommends may not.

On an existing system, install it with:

sudo apt install upki

Then trigger the initial data download:

sudo systemctl start upki-fetch.service

The first command installs the package. The second starts the initial fetch rather than waiting for the next scheduled update.

Until the first dataset has been downloaded, curl behaves as it did before the revocation integration was available. A newly installed package alone does not mean the system is already checking against current revocation data.

Checking a certificate manually

#

You can also extract the certificate chain presented by a server and pass it to upki:

curl -sw '%{certs}' https://ubuntu.com -o /dev/null | upki revocation check

This is useful for diagnostics and monitoring scripts. It lets you inspect revocation status separately from the behavior of a larger application.

03. 🚨 Why Canonical Is Making This Change Now

#

Canonical’s announcement points to a specific certificate security incident.

On October 17, 2026, a security researcher discovered that eight intermediate CA certificates associated with eMudhra had cryptographically weak private keys.

The problem was severe: the private keys were small enough to recover through trivial brute-force attempts. One of the keys was literally the number 4.

Anyone who recovered an affected intermediate CA private key could potentially use it to create certificates trusted by systems that accepted the corresponding CA chain.

Firefox and Chrome moved quickly to block the affected certificates. eMudhra revoked all eight intermediate certificates on October 18.

The incident exposed a gap between browser security and the wider Linux software ecosystem.

Browsers have mechanisms for distributing revocation information quickly. Other applications may depend on the operating system’s CA bundle, which generally changes only when a distribution publishes and users install an updated package.

That creates a delay between discovering a compromised certificate authority and ensuring that every application rejects certificates associated with it.

The eMudhra incident made that delay difficult to ignore.

Why curl is the first target

#

The upki project reached its 1.0 release in October 2026. Ubuntu’s initial integration focuses on curl, rather than changing the behavior of every OpenSSL application at once.

That is a relatively contained starting point:

• curl is widely installed and used in scripts, CI pipelines, and infrastructure automation.
• Its TLS integration provides a practical way to test the new verification mechanism.
• The change can be isolated to Ubuntu’s curl packaging.
• If compatibility problems appear, reverting the integration is more manageable than rolling back a system-wide OpenSSL change.

One detail worth emphasizing is that this is not an upstream curl feature change. Canonical implemented the integration in Ubuntu’s packaging. Other distributions can ship the upki package without automatically enabling revocation checks in their own curl builds.

For example, Arch Linux adding upki to its repositories does not, by itself, mean its curl package performs the same checks.

For more context on the distribution’s broader platform changes, see Ubuntu 26.10’s Linux, installer, and system-level updates.

04. ⚠️ Four Important Limitations to Understand

#

It would be a mistake to treat upki as a universal solution to certificate revocation.

Ubuntu’s initial integration has a defined scope, and several scenarios need separate consideration.

Offline systems need a different strategy

#

The air-gapped case is particularly easy to overlook.

Imagine a server that has been disconnected from the network for three months. Its local revocation dataset may also be three months old.

The system cannot check information it has never received. A certificate revoked during that period might therefore be evaluated against outdated data.

The absence of a network error does not mean the revocation dataset is current.

Organizations operating offline infrastructure should plan a controlled way to distribute updated revocation data and monitor when the last successful refresh occurred.

Private CA certificates remain a separate problem

#

The public CRLite dataset does not cover an organization’s private certificate infrastructure.

That means internal certificates issued by a private CA are not suddenly subject to the same public revocation checks.

This limitation can help avoid unexpected breakage in enterprise environments, but it also means administrators cannot assume that upki provides complete revocation coverage for their internal PKI.

Do not use -k to work around certificate failures

#

One rule remains unchanged:

curl -k

The --insecure option disables certificate verification. It does not merely skip the revocation check.

If a connection starts failing after upgrading to Ubuntu 26.10, identify the actual verification error before changing the command. An expired certificate, hostname mismatch, untrusted issuer, and revoked certificate are different problems.

Adding -k may make the connection work again, but it also removes the protections that TLS certificate validation is supposed to provide.

05. 🛠️ Ubuntu 27.04 Could Make This a System-Wide Change

#

Ubuntu 26.10 introduces the feature through curl packaging. Canonical’s next target is more ambitious.

For Ubuntu 27.04, the Foundations team plans to integrate upki directly into Ubuntu’s OpenSSL build.

If implemented as planned, ordinary OpenSSL certificate-verification flows will also be able to consult the local revocation dataset. Applications that link directly against OpenSSL could benefit without requiring their developers to add application-specific revocation code.

Canonical estimates that this could cover more than 1,000 packages.

That would change the scope considerably.

Today, an application using OpenSSL may successfully establish a TLS connection even when the relevant certificate has been revoked, depending on its configuration and verification behavior. With the planned integration, more of those applications could inherit revocation checking from the system’s TLS foundation.

The change could also expose compatibility assumptions that have remained hidden for years.

Potential trouble spots include:

• Legacy services pinned to old container images.
• Internal applications relying on private certificate authorities.
• SDKs and applications with custom certificate-verification callbacks.
• Workloads using hardcoded certificate chains or outdated trust configurations.
• Offline systems that cannot keep revocation data current.

The issue is not whether stronger certificate validation is desirable. It is whether existing infrastructure is prepared for stricter verification behavior.

What infrastructure engineers should do now

#

Ubuntu 26.10 provides a useful testing window before the planned OpenSSL integration.

If you maintain CI pipelines or production services, consider the following:

1. Install upki on an Ubuntu 26.10 test system.
2. Trigger the initial revocation-data download.
3. Confirm that the dataset refresh service is operating.
4. Run your normal API and HTTPS integration tests using the Ubuntu 26.10 curl package.
5. Investigate failures caused by revoked certificates rather than bypassing verification.
6. Test private CA and container-based workloads separately.
7. Record any applications that depend on custom certificate-verification behavior.

The goal is to discover problems while the integration is still limited to curl, rather than encountering them during a broader OpenSSL rollout.

For additional background on Ubuntu’s security and infrastructure changes, see Ubuntu 26.04’s security and platform updates.

Ubuntu 26.10’s curl integration is a relatively small packaging change with implications that extend well beyond one command-line utility.

For years, Linux applications could rely on certificate-chain validation without necessarily receiving the same timely revocation information available to browsers. upki offers a way to narrow that gap using compressed local data rather than per-connection network queries.

The immediate change affects curl. The planned Ubuntu 27.04 integration could affect a much larger part of the software ecosystem.

For infrastructure teams, the best time to test those assumptions is before the system-wide change arrives—not at 3:00 AM when an unattended service suddenly starts returning curl: (60).