An update on upki

The five core upki components

Canonical released **version 0.1.0** of upki to bring browser-grade certificate revocation to the Linux ecosystem. Lead developers Dirkjan and Joe built the system to standardize how Linux utilities, package managers, and language runtimes handle security certificates. The project uses **CRLite**, a data format that compresses revocation information to make it searchable at scale without massive memory overhead. The upki repository functions as a Cargo workspace containing five distinct crates. Each component handles a specific part of the security pipeline, from the core engine to language integrations.

• upki: This is the primary library and command-line tool. It manages the revocation query engine and the logic for syncing filter updates from the server.
• upki-mirror: This server-side tool fetches CRLite filters from Mozilla. It validates the data so standard web servers like Nginx can distribute it to clients.
• upki-ffi: This crate provides a C Foreign Function Interface. It allows developers to use upki in languages like **Go**, **C++**, and **C** by auto-generating header files.
• rustls-upki: This integration links the revocation engine to the **rustls** library. It allows any Rust application to perform transparent certificate checks.
• revoke-test: This infrastructure validates the system. It tests revocation queries against a database of known-revoked certificates to ensure accuracy.

The development team recently moved the revocation interface directly into the library. This change allows other Rust projects to include upki as a direct dependency rather than relying on the command-line interface.

How to test the release

Developers can now test the early version of upki using the **Rust toolchain**. Canonical recommends using the **rustup snap** on Ubuntu to manage the installation. Users must first install the build-essential and curl packages to prepare the environment. After setting up the stable Rust toolchain, the cargo install command adds upki to the system path. Users must then run the fetch command to download the initial revocation data. This manual step will eventually happen automatically in the background when Canonical integrates the tool into the operating system. Testing the system involves piping certificate data from curl directly into the upki utility. A successful check against a site like Google will return a **NotRevoked** status. This demonstrates that the local engine can verify the status of a live certificate against the downloaded CRLite filters. The team released documentation for the C FFI and Rust crates to help developers integrate the tool. Dirkjan also published a **Go demo** to show how non-Rust applications can leverage the library. This early feedback phase will guide the team as they refine the query engine.

Canonical scales up the infrastructure

The project is moving from a development phase to a production-ready environment. Canonical is currently deploying infrastructure to host CRLite filters for the wider community. Early testers currently fetch data from a pre-production server at **upki.rustls.dev**, but this will soon change. The team built a **Juju charm** to manage the upki-mirror on **Kubernetes**. This charm packages the mirror binary inside a "chiselled Rock," which is a stripped-down, secure container image. Canonical will host this data at **crlite.ubuntu.com** to ensure high availability for Ubuntu users. Performance remains a high priority for the next phase of development. The current engine reads several CRLite filter files into memory for every check. The team plans to run **benchmarking tests** on the initial data fetch and individual revocation queries to identify bottlenecks. The Ubuntu Foundations team is currently packaging these components for the official Ubuntu archive. This work paves the way for users to install the tool via a simple apt command. Canonical intends to offer an opt-in preview in **Ubuntu 26.04 LTS** and plans to enable the tool by default in **Ubuntu 26.10**.

Solving the broken certificate chain

The upki project aims to fix a common usability issue involving intermediate certificates. Many web servers fail to send the full chain of certificates required to verify a connection. Browsers like **Firefox** and **Chrome** solve this by preloading certificates or fetching them silently in the background. Linux command-line utilities like curl often fail when they encounter these misconfigured servers. They return an **UNKNOWN_ISSUER** error because they lack the intermediate certificates. This creates a discrepancy where a website works in a browser but fails in a terminal. Because upki maintains a local data store, it can ship a known set of intermediate certificates alongside revocation data. This approach improves connection reliability for all Linux utilities. It also provides a **privacy benefit** by preventing the system from contacting a Certificate Authority to ask for missing data. This functionality brings non-browser clients to parity with modern web browsers. It ensures that system updates and API calls do not fail due to common server misconfigurations. The local cache makes the entire verification process faster and more private than traditional methods.

The shift to post-quantum security

The development roadmap includes support for **Merkle Tree Certificates (MTCs)**. This technology addresses the security challenges posed by quantum computing. Post-quantum cryptographic signatures are significantly larger than the signatures used today. An **ML-DSA-44** signature requires **2,420 bytes**, while a standard **ECDSA-P256** signature uses only **64 bytes**. If Linux systems simply swapped old algorithms for new ones, the size of every TLS handshake would increase by tens of kilobytes. This would cause noticeable latency on every encrypted connection. MTCs solve this by changing how systems validate batches of certificates. Instead of sending a full chain with multiple signatures, a Certificate Authority signs a single root hash of a Merkle Tree. The server then provides a compact proof that its certificate exists within that tree.

• Smaller handshakes: MTCs reduce the amount of data sent during a connection.
• Local caching: upki can store tree heads locally to shorten the proofs needed for validation.
• Quantum readiness: The system prepares Linux for a future where traditional encryption is vulnerable.

While MTCs remain experimental, companies like **Cloudflare** and **Google** are already testing them. By building support into upki now, Canonical ensures that Ubuntu will be ready for the next generation of web security. This proactive approach prevents the performance degradation that would otherwise come with post-quantum encryption. The project also plans to enforce **Certificate Transparency (CT)**. This requires servers to prove that their certificates appear in public, auditable logs. By integrating CT enforcement into upki, Canonical will prevent attackers from using fraudulent certificates that haven't been publicly recorded.