Serve the CA certificate for browsers/mobile at http://mitmux.cert/

Browser/mobile setup previously meant "find ca.pem on disk and import
it manually" - awkward on a phone or tablet especially, which has no
convenient way to get a file onto the device at all short of emailing
it to yourself or similar. Any client already configured to proxy
through mitmux can now just visit http://mitmux.cert/ and get the cert
directly, with Content-Type: application/x-x509-ca-cert triggering
iOS/Android's native "install this certificate" prompt.

Same idea as mitmproxy's own http://mitm.it/, arrived at independently
rather than reusing their domain - mitmux.cert isn't a registered TLD,
so it can never collide with a real site someone meant to visit.
Deliberately HTTP-only: fetching it over HTTPS would require the client
to already trust mitmux's CA to MITM that very connection, the exact
chicken-and-egg problem this exists to solve, so it's not attempted on
the CONNECT/TLS path at all.

internal/proxy/proxy.go: isCertDownloadHost matches the hostname
case-insensitively regardless of port; handleHTTP checks it before
ever dialing upstream and answers directly via serveCACert, using the
CA's own CertPEM bytes already held in memory. Short-circuits before
record() is ever reached, so the download itself never pollutes
history.

Verified live: fetched http://mitmux.cert/ through a real running
proxy and confirmed the downloaded bytes are byte-identical to the
actual ca.pem on disk (diff, not just "the request succeeded");
confirmed a request with an explicit port and a path still matches;
confirmed normal proxying to an unrelated host is completely
unaffected; confirmed via direct SQLite query that the cert-download
requests never appear in history while a normal request in the same
session does.

Also documented (no code needed): any standard proxy-switcher extension
(FoxyProxy, etc.) or a phone/tablet's own Wi-Fi proxy setting already
works with mitmux exactly like it would with Burp/ZAP/Caido, since it's
a normal forward proxy speaking the standard protocol. This was true
before but never actually spelled out in the README for the phone/
tablet case specifically, which is a real, common daily workflow.

go build/vet/gofmt/test/mod tidy all clean.

1 files changed, 58 insertions, 0 deletions

diff --git a/PLAN.md b/PLAN.md
index f113bd8..0d1d52e 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -378,3 +378,61 @@ Skipped deliberately (from the research, matches this tool's stated
 scope): active/passive vulnerability scanning, plugin marketplace,
 Collaborator/OAST, team collaboration, CI integration, client TLS
 (mutual-TLS) certs, invisible/non-proxy-aware proxying.
+
+## Licensing, packaging, and browser/mobile support
+
+Licensed GPL-3.0 (see `LICENSE`) - deliberate for a security tool
+specifically: keeps derivatives open, a common and well-regarded choice
+in that community, and doesn't foreclose the author dual-licensing the
+code commercially later (remains available as sole copyright holder,
+independent of the public license) or relicensing outright in the
+future (unconstrained for as long as the codebase has no outside
+contributors - the harder case only starts once other people's
+copyrighted changes are in it).
+
+Added a `-version` flag to both binaries (`internal/version`, set via
+`-ldflags` at build time, defaulting to "dev" otherwise) and a
+`Makefile` (`make build`/`make test`/`make release`/`make install`).
+Cross-platform support turned out to already be ~95% there by accident
+of earlier choices - pure-Go SQLite (no CGO), `os.UserConfigDir()`
+instead of a hardcoded XDG path, nothing Linux-specific anywhere in the
+codebase - so making it explicit was verification and packaging work,
+not a rewrite: `make release` was run for real and produced correctly-
+formatted binaries (confirmed with `file`, not just an exit code) for
+linux/darwin/windows/freebsd across amd64+arm64 where applicable, all
+`CGO_ENABLED=0`. Linux remains the only platform actually run during
+development, though - macOS/Windows/FreeBSD compile clean and pass `go
+vet` but haven't touched real hardware, documented honestly as such in
+the README's Platforms section rather than as a tested claim.
+
+CA certificate distribution for browsers/mobile: `mitmuxd` now
+recognizes the magic hostname `mitmux.cert` on its plain-HTTP proxy
+path and serves its own CA certificate as a download
+(`internal/proxy/proxy.go`'s `serveCACert`/`isCertDownloadHost`) -
+`http://mitmux.cert/` from any client already configured to proxy
+through mitmux gets the cert with `Content-Type:
+application/x-x509-ca-cert`, which triggers iOS/Android's native
+"install this certificate" prompt directly. Same idea as mitmproxy's
+own `http://mitm.it/`, arrived at independently rather than reusing
+their domain - `.cert` isn't a registered TLD, so it can never collide
+with a real site. Deliberately HTTP-only: fetching it over HTTPS would
+require the client to already trust mitmux's CA to MITM that
+connection, the exact chicken-and-egg problem this exists to solve.
+This matters most for mobile devices, which otherwise have no
+convenient way to get a certificate file onto the device at all short
+of emailing it to yourself or similar. Verified live: fetched
+`http://mitmux.cert/` through a real running proxy, confirmed the
+downloaded bytes are byte-identical to the actual `ca.pem` on disk,
+confirmed a request with an explicit port and path still matches,
+confirmed normal proxying to an unrelated host is unaffected, and
+confirmed the cert-download request itself never gets recorded to
+history (it's answered before `record()` is ever reached).
+
+Any standard proxy-switcher extension (FoxyProxy, etc.) or a phone/
+tablet's own Wi-Fi proxy setting already works with mitmux exactly like
+it would with Burp/ZAP/Caido - mitmux is a normal forward proxy
+speaking the standard protocol, nothing proxy-switcher-specific to
+support. No code needed here, just documented clearly in the README's
+Quick start (previously this was implied but never actually spelled
+out for a phone/tablet setup, which is a real, common daily workflow
+this tool hadn't explicitly walked through before).