A certificate only for itself

The warning that seems wrong at first

Anyone opening JiCo in a browser for the first time sees something that initially raises suspicion: a certificate warning of the kind one otherwise knows from badly maintained websites. That seems paradoxical for a program that runs exclusively locally and never leaves your own machine — why an HTTPS connection at all, when sender and recipient are the same computer?

The answer lies precisely in what actually travels over this connection: the Jira access token, the approval decisions, the entire chat with the model. An unencrypted local connection would be more convenient, but it would be open to attack from any other program on the same machine trying to read along — a plain-text protocol for what is of all things the most sensitive connection in the whole system would be the wrong place to economise.

A certificate with only one single job

The panel therefore issues itself a certificate — explicitly without the rights of a real certification authority. It is valid only for 127.0.0.1 and localhost, and so can never be misused for another address, even if it were copied. Its validity is limited to at most 825 days — the same upper limit that the major browser makers now enforce for all certificates, because a shorter window limits the consequences of a stolen private key.

For the browser to show this certificate as trusted at all, it has to be entered once into the system keychain (macOS) or the user's certificate store (Windows) — with an explicit prompt when the panel starts, not automatically in the background. This step is logged, with the certificate's fingerprint, and can be undone by the same route.

Why this prompt is not a loss of control

Entering a self-signed certificate into your own keychain formally means trusting the system to a certain degree — which is why exactly this trust is named for what it is in JiCo's own test programme for security officers: a limit, not an invisible side matter. The system itself confines this trust technically as narrowly as possible: the tools with which a certificate can be entered into the system store at all (security on macOS, certutil on Windows) are permitted by the egress guard explicitly only with precisely those subcommands that are necessary for this one specific certificate — not as a general permission for arbitrary certificate operations.

Anyone who wants to control the details centrally instead of answering every prompt individually can also distribute the certificate to all machines in the company by mobile device management — a route that is the usual one for IT departments anyway when many installations of the same kind are due.

Not every operating system handles this the same way

macOS and Windows both come with their own, system-wide certificate store, into which the panel certificate can be entered with a single prompt — there it is anchored by the respective system dialogue, which JiCo addresses directly. On Linux this one shared store does not exist in that form; there the route additionally differs depending on the browser used, which is why JiCo points to a more detailed set of instructions at this point instead of promising a single automated step that technically cannot exist in a uniform way. This is not a pretext for supporting Linux less well, but an honest consequence of the different trust models of the respective platform.

What this construction deliberately is not

A self-signed certificate restricted to loopback addresses is explicitly not a real certification authority — it cannot issue a further certificate for any other address, and it would be worthless to an attacker even if it fell into their hands, as long as they did not also have physical or administrative access to precisely this one machine. That is the decisive difference from a compromised public certification authority, whose misuse could draw entirely different circles.

The honest flip side is likewise stated in the test programme itself: anyone with local administrator rights on the device can in principle appropriate any file of the local store — even on Windows with a restricted access list. The certificate alone therefore does not protect against a compromised administrator account; against that, only device management itself helps, meaning the question of who has administrator rights in the first place, plus proper full-disk encryption.

A small decision with considerable symbolic force

A single, locally confined certificate looks like a technical footnote at first glance. But it is a vivid example of a pattern that runs through JiCo as a whole: instead of relying on a single convenient measure, several layers are laid over one another, each narrowly confining the others — a certificate valid only for itself, a guard that permits only two specific system commands, a prompt that is never silently skipped. Small taken on its own, but carried through consistently in every single place.