v0.2.0 — the visitor side just works

The visitor side works without special knowledge. v0.1.0 shipped the mechanism; this is the release where following the README is enough.

The proxy was refusing every site — correctly

It relayed through pit.moshcode.sh:443, which only works if the gateway passes TLS through by SNI. It terminates instead, so every name presented the gateway's own certificate:

refuse alt.2600:     key mismatch, presented ErIMn03cxhS+PK7UKUcSOY5pqegEhCn8Xvw4k3LqAnw=
refuse chovy.hacker: key mismatch, presented ErIMn03cxhS+PK7UKUcSOY5pqegEhCn8Xvw4k3LqAnw=
refuse seo.rank:     key mismatch, presented ErIMn03cxhS+PK7UKUcSOY5pqegEhCn8Xvw4k3LqAnw=

Three names, one key. The proxy was doing its job and looked broken doing it. It now dials the origin the registry names, falling back to the gateway only when there is no target — which changes nothing about trust, since the pin still decides whether the connection lives (#13).

moshpit-trust never touched the store curl reads

It covered NSS and the macOS keychain and left /etc/ssl/certs alone, so curl <name> still failed on a machine that had been "set up" — reading as the whole scheme being broken rather than one store being missed. It now installs into the distribution's anchor directory and rebuilds the bundle, verifying the bundle contains the root rather than that a file landed in a directory: update-ca-certificates ignores anything not ending in .crt, silently, exiting zero (#13).

The origin stopped redirecting to a certificate nobody can verify

Port 80 serves the site instead of upgrading to an HTTPS URL a browser can neither resolve nor validate (#14).

Deployment

/opt/moshpit is a checkout, so merging ships (#15).

Verified

On a live box, over stock configuration — no gateway override, no local pin file:

ok alt.2600     (registry) TLSv1.3 hybrid-pq
ok auto.hacker  (registry) TLSv1.3 hybrid-pq
ok seo.rank     (registry) TLSv1.3 hybrid-pq
ok chovy.hacker (registry) TLSv1.3 hybrid-pq

curl returns 200 for each with no -k. 61 tests pass, up from 51.

Known limitation

An override supplies pins and no target, so an override-pinned name still relays through the gateway. Overrides exist for private grids that may have no registry at all, so skipping it is deliberate — letting an override carry its own target is the follow-up.

🤖 Generated with Claude Code

v0.1.0 — a name serves itself

First release. A Moshpit name now goes from "pointed in the dashboard" to "serving over TLS" without anyone touching the box.

The problem this solves

No CA will issue a certificate for .hacker, .rank or .2600 — the CA/Browser Forum stopped issuing for endings outside the DNS root in 2015. So a Moshpit site is either plaintext, or it presents a certificate every browser rejects.

The answer here is a pin: SHA-256 over the origin's SubjectPublicKeyInfo, published in the registry. It replaces the certificate authority rather than supplementing it — one exact key, named by its owner, instead of delegating trust to whichever of ~150 CAs will sign. It is also the part of the design that survives a quantum adversary: a chain is authenticated by RSA or ECDSA signatures, which Shor's algorithm breaks; a pin is authenticated by a hash, and Grover's only halves preimage resistance.

What is in it

moshpit-proxy — runs on the visitor's machine. Terminates TLS with a locally-trusted certificate and verifies the origin against its published pin. Reports whether each origin leg negotiated X25519MLKEM768, and can refuse any that did not.

moshpit-trust — sets a computer up to open Moshpit sites, across NSS, the macOS keychain and per-profile Firefox stores. It asks once, verifies by reading back what it wrote, and never shows the user the word "certificate".

scripts/setup-origin.sh — key, certificate, nginx block, reload, then publishes the pin and sets the target through the registry API. One command, and it re-reads the pin from the endpoint clients actually query rather than trusting its own 201.

scripts/moshpit-reconcile.sh + systemd timer — asks the registry which names point at this host and configures the ones that are not configured yet. Pointing a name becomes the only step there is.

nginx/moshpit-origin.conf — TLS 1.3 only, X25519MLKEM768 first, no HSTS, session tickets off.

Verified against a live deployment

Not a mock. chovy.hacker, seo.rank and alt.2600 are served by this code, each with a published pin that matches the key nginx actually presents. auto.hacker was claimed and pointed with nothing done on the box, and the reconciler had it serving a minute later:

$ curl -k --pinnedpubkey "sha256//<published pin>" https://auto.hacker/
200

51 tests pass.

Known sharp edges

• The visitor side is a real install. Without moshpit-proxy running locally, curl alt.2600 fails on a self-signed certificate — correctly, since the pin is the only thing that makes it trustworthy and curl does not know about it.
• Adding an origin block to a box that has never declared default_server can silently make the new name the default vhost for :443. The script warns rather than editing an unrelated site's config.

🤖 Generated with Claude Code