The certificate isn't trusted

The site resolves and loads, but the browser shows a warning instead of a lock. Two things can cause it, and they need different fixes.

1. The CA is not trusted

The Keychain prompt from first run was dismissed, or the trust was removed later.

Check:

security find-certificate -c rexenv -a login.keychain

Settings can re-run the trust step. It asks for your login password rather than an admin one, because the CA lives in your login keychain.

2. The site’s own certificate is stale

The CA is trusted but this site’s leaf is wrong — usually after changing a domain, or on a multisite that gained a subdomain the certificate does not cover.

rex site cert myshop.rex                # what the current certificate says
rex site cert myshop.rex --regenerate   # issue a fresh leaf

Then hard-reload. Browsers cache certificates per session, so the old one can persist after the fix.

Safari refuses while Chrome is fine

This one has a specific cause

Safari and WebKit reject leaf certificates valid for more than 398 days, even when the issuing CA is fully trusted — and the error names something unrelated (CSSMERR_TP_CERT_SUSPENDED), which sends people looking in the wrong place.

rexenv issues short-lived leaves precisely to stay under that cap. If you hit this with a certificate rexenv issued, regenerate it and report it — a leaf over the cap is a bug.

Only in one browser

Firefox keeps its own certificate store and does not read the macOS keychain by default. Either enable Settings → Privacy & Security → “Allow Firefox to automatically trust third-party root certificates”, or import rexenv’s CA into Firefox directly.

Chrome and Safari use the system store, so if both are happy and only Firefox complains, this is why.

After a reinstall

Removing rexenv with Settings → Remove system changes removes the CA trust, and a fresh install generates a new CA. Old certificates from the previous install will not validate against it — regenerate them, or recreate the sites.