HTTPS and DNS

Two separate mechanisms make https://myshop.rex work, and it is worth knowing which is which when one of them breaks.

DNS — how the name resolves

rexenv runs a small DNS server that answers *.rex with 127.0.0.1, and writes /etc/resolver/rex so macOS asks it for that TLD. That file is the one-time admin prompt on first run.

No /etc/hosts editing, and no entry to add per site: a new site resolves the moment it exists.

The DNS outlives the app

It runs from a per-user LaunchAgent, so quitting rexenv does not stop it — your sites keep resolving, and a watchdog restarts it if it dies. A site that stops resolving because you closed a window would be a worse experience than one that keeps answering.

Other TLDs

.rex is the always-installed backbone, but the default TLD for new sites is configurable — .test, or anything else. Picking one installs its resolver file the same way, with one admin prompt at that moment.

rex tld --set test

HTTPS — how the certificate is trusted

rexenv generates a certificate authority on your machine and asks, once, for permission to trust it in your login keychain. Every site then gets a leaf certificate signed by that CA, with a wildcard SAN for subdomain multisite.

The result is a real green lock — not a bypassed warning, not an exception you clicked through.

Three properties worth stating plainly:

• The CA signs only your local sites. It is not a general-purpose authority for your machine.
• The private key never leaves your Mac and is not shared between machines.
• Trust lives in your login keychain, not the System keychain — user-level blast radius, and removable without admin rights.

Certificates are short-lived on purpose

Leaves are issued for under 398 days, because Safari and WebKit reject longer-lived certificates outright — with the CA trusted and Chrome perfectly happy, Safari would still refuse. Regenerate one at any time:

rex site cert myshop.rex --regenerate

The edge

Caddy terminates TLS on ports 80 and 443, then forwards to the shared nginx by hostname. Its admin interface is a unix socket with 0600 permissions, never TCP.

That last point is a security property, not a preference: a TCP admin API on a root-owned proxy is arbitrary file read and write as root for anything that can reach it. rexenv never binds or queries the conventional TCP admin port, which also means it can never reach into a Caddy you run yourself.

When it does not work

• The name will not resolve → DNS not resolving
• The lock is broken or the browser warns → Certificate not trusted
• Nothing is listening on 443 → Port 80 or 443 in use