Two commits. Together they are why curl https://chovy.hacker never verified.

1. dns enable never turned proxy mode on

Everything needed was already built and none of it was connected:

• moshpit-proxy verifies an origin against the registry pin and re-signs with a root it generates locally.
• addressAnswer knows how to point every live name at that proxy (proxied: true).
• dns start --proxy can switch it on.
• dns enable already installs the root the proxy signs with.

Nothing ever passed --proxy. So names resolved straight to their origin, a stock client got a certificate no CA had signed, and the trust store was populated for a proxy that was never on the path. dns enable now probes for the proxy and starts the bridge in proxy mode when it finds one.

The probe is a TLS handshake, not a connect. This is the part that matters. proxyReachable answers "is something listening", and on one common class of machine the two answers differ in the worst possible way: an origin runs nginx on 0.0.0.0:443, which covers loopback — so a connect succeeds, proxy mode goes on, and every live Moshpit name on the machine is pointed at a web server that has never heard of them. That is not a certificate problem, it is every name serving the wrong site at once.

So proxyServes() completes a handshake and checks who issued the certificate. The proxy mints a leaf per name from the root it generated here; nginx serves the origin's own self-signed certificate, issued by itself. Nothing is trusted in the process — the peer certificate is read rather than verified, and the only thing taken from it is the issuer name (verifying properly would need the root already installed, which has not happened yet at that point).

Refusing is the default in every uncertain case, because proxy mode with nothing behind it resolves every name and then refuses every connection — the sites look down while dig stays healthy. A bridge this run did not start keeps its own mode, so the probe is skipped rather than run and discarded; announcing a proxy and retracting it two lines later is worse than not looking. --no-proxy opts out.

2. dns trust would install a CA as a trust anchor

moshcode dns trust <name> installed whatever the socket served, provided the registry published a matching pin. The pin proves the registry vouches for that key; it says nothing about whether trusting it is bounded.

A certificate installed by this path becomes a trust anchor, and an anchor marked CA:TRUE may issue for any name. The code claimed the opposite — "its SAN limits it to this one name" — but a SAN describes what a certificate speaks for, not what a key trusted as an authority may sign. Same hole requireNameConstraints closes on the root path, arriving by the other door.

It went unnoticed because openssl's req -x509 defaults to CA:TRUE, so every origin created by setup-origin.sh serves exactly the shape that must be refused, and it is indistinguishable from a correct one until someone trusts it. All three names on the dev box are CA:TRUE today.

The refusal names a remedy that costs nothing — re-issuing from the same key leaves the published pin untouched — because a gate with no way forward is a gate people route around.

Pairs with profullstack/moshpit-proxy#18, which changes what is issued.

Tests

13 new (10 proxy mode, 3 trust). The proxy probe tests use real openssl chains and a real TLS server, since what separates the two cases is the issuer on a completed handshake and a stub would only prove the stub sets the field the code reads. Full suite 1073 pass / 0 fail.

🤖 Generated with Claude Code