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.

The first checks below are macOS’s, where the CA lives in your login keychain. On Linux it lives in two stores at once — those checks are at the end.

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 — its trust setting and the certificate itself, from your login keychain — 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.

On Linux

There is no single trust store, so rexenv writes the CA twice: into your browsers’ NSS databases (~/.pki/nssdb, the snap Chromium’s own once that snap has run, and each Firefox profile’s) with no prompt, and into the system store, for curl, PHP and WP-CLI, with one password dialog. “CA trusted” in Settings means both hold the current CA.

certutil -d sql:$HOME/.pki/nssdb -L | grep -i rexenv                 # the browsers' half
ls -l /usr/local/share/ca-certificates/rexenv-local-ca.crt            # the system half
curl -I https://yoursite.rex                                          # no -k: the system half works

• The browser warns but curl is fine — the NSS half is missing, typically for a browser that first ran after setup: a snap browser keeps its own database and cannot see ~/.pki. Trust the CA again from Settings → DNS & SSL, and restart the browser.
• curl or PHP fails but the browser is fine — the system half is missing, which is the part that needed your password. Trusting again asks for it once.
• Firefox has a card of its own in Settings → DNS & SSL, including the CA file to import by hand if it still warns: ~/.local/share/rexenv/ca/rexenv-ca.pem.