Ubuntu curl: test the client and revocation dataset
A revocation dataset needs to reach the client that runs the job. This guide connects the curl binary to data collection and the observed connection result.
Czytaj po portugalskuBy Pentesty
Establish the scope before planning the change
The Ubuntu team’s announcement, dated November 10, 2026, introduces upki in Ubuntu 26.10 curl. Previous behavior remains before the first fetch; the timer schedules a fetch every six hours. Broader OpenSSL integration in 27.04 is a plan.
The implementation record documents the OpenSSL build and the s390x and i386 exclusions in that integration. Before applying this description to your environment, confirm architecture, package origin and effective configuration. A distribution name in an inventory does not establish which client an application runs.
Find the client making the request
Choose a business automation, such as a finance integration, and identify where its request originates. Record its image, user, the path returned by command -v curl and the output of curl --version. The curl documentation explains how this output identifies TLS libraries; MultiSSL builds can offer backend choices.
Repeat the inventory inside the runner or container used in production. The tool available in an administrator’s terminal may differ from the one used by a scheduled task. If an application embeds libcurl, ask the artifact owner to identify its library and integration rather than inferring coverage from the system executable.
- Associate each result with the service, image and user examined.
- Retain package provenance and distinguish distribution components from custom builds.
- Assign responsibility for repeating the check when the image or backend changes.
Check collection in the right context
A listed package and usable data are different conditions. The upki packaging guide describes per-user configuration before system configuration, a cache and a configurable fetch server. Check which paths the job’s user actually uses and can read.
On an Ubuntu environment within scope, examine the result of upki-fetch.service and timer history. The documented action to start collection is sudo systemctl start upki-fetch.service, performed through the company’s change process. Then check completion and available data; a quiet console does not replace inspecting the service result.
Assign an owner for update failures, including those following a proxy, inspection-certificate or outbound-policy change. Agree on an alert condition for the last successful fetch and a process for reviewing old data. These are proposed operating conditions, without asserting a universal certificate-update deadline.
Compare results and retain the reason
In authorized staging, compare a valid connection with the revoked example https://revoked.badssl.com/ identified by Ubuntu. Retain the command, time, error output and client context. The curl error list describes code 60 as a certificate-authentication failure; that code alone does not identify revocation.
Read the complete reason and investigate differences between the valid control and revoked test. Keep certificate validation enabled. If results differ from expectations, leave the decision open until you distinguish trust problems, configuration paths and client behavior.
Include an isolated startup scenario without fetch access and another with an interrupted update. Record behavior with absent or old data and who decides whether the business job may run. This guide proposes checks; Pentesty has not executed these tests in the reader’s environment.
Separate public trust from private PKI
The upki project describes revocation for publicly trusted authorities. The OpenSSL callback contract preserves prior verification when a chain is not covered by its data. Document the private PKI revocation policy separately.
Acceptance of an integration should connect the client, data and observed behavior. Our analysis of connection ownership helps assign that decision; the guide to running OpenSSL libraries explores the package-to-process link. Use these records to review exceptions and repeat the test after changes.
Frequently asked questions
Does installing the package prove revocation checking?
No. Examine the running client, the data it can use and the result of a controlled test. Record the conditions that remain unverified.
Does a scheduled fetch prove the data arrived?
Check the execution result, cache access and recorded failures. A schedule describes a planned attempt; its result helps establish what happened.
Does the public test also validate my internal CA?
Do not assume that coverage. Define a separate test for the internal chain and record the revocation mechanism the application actually uses.
When should the assessment be repeated?
After changes to the package, image, user, backend or collection path. Also maintain a periodic review appropriate to the integration’s criticality.
Sources and references
- Ubuntu: upki announcement
- Launchpad: curl integration
- curl: options and errors
- upki: packaging and collection
- upki: project scope
- upki: OpenSSL contract
Original Pentesty analysis, published November 11, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.