mkcert Web UI

Self-hosted certificate management, honestly reviewed. What you actually get when you wrap mkcert in a Node.js web interface.

TL;DR

• What it is: A web-based dashboard that wraps the mkcert CLI tool, letting you generate and manage locally-trusted SSL certificates without touching the terminal [2][README].
• Who it’s for: Developers and homelabbers who already use mkcert, find themselves forgetting CLI flags, and want a browser-based interface over SSH’d into a box. Not for non-technical founders — this assumes you know what a certificate authority is [2].
• Cost savings: There’s nothing to pay. mkcert Web UI is GPL-3.0 open source, and local dev certificates have always been free — the value here is time, not money [README].
• Key strength: It eliminates the terminal for common mkcert operations. You get a real UI with certificate expiry monitoring, email alerts, SCEP enrollment, and OIDC SSO — substantially more than the CLI alone [README].
• Key weakness: 206 GitHub stars signals a very early-stage project. It started as one person’s scratch-their-own-itch weekend build and has grown, but you’re betting on a single maintainer [2][GitHub].

---

What is mkcert Web UI

The story starts with mkcert — the CLI tool by Filippo Valsorda that collapses the entire “set up a local certificate authority and generate trusted certificates for localhost” workflow into two commands [1][3]. Developers have loved it since it launched; one Medium author called it life-changing after years of maintaining an openssl cheat sheet [1]. That part is well-established.

mkcert Web UI is a separate project by Jeff Caldwell that wraps mkcert in a Node.js web server. The creator posted it to r/selfhosted explaining the origin story directly: “I use mkcert a lot for local HTTPS certs, but I kept forgetting the flags or where I saved stuff, so I hacked together a little web UI to make it easier.” [2]

That’s an honest pitch. What started as a lightweight wrapper has grown into a more complete tool — the current v3.x release adds SCEP (Simple Certificate Enrollment Protocol) for automatic device enrollment, OIDC SSO, email expiry alerts, certificate monitoring, and a REST API. The architecture is still a Node.js server that shells out to mkcert under the hood [README].

It sits at 206 GitHub stars with 9 forks as of this review — a fraction of mkcert’s 60K+ stars, which tells you exactly what you’re dealing with: a useful niche tool with thin community coverage, not an established open-source project with multiple maintainers.

---

Why people choose it

There isn’t a corpus of independent reviews for mkcert Web UI specifically — the project is too small. What exists is the mkcert CLI ecosystem, which tells you why the underlying tool matters, and the Reddit post from the creator, which tells you why the web UI exists.

The underlying pain point is real. Before mkcert, setting up a locally-trusted development CA meant running a series of openssl commands, installing roots into your OS trust store manually, and dealing with browser security warnings on localhost. One developer’s Medium post describes the workflow: create a local CA, generate a root certificate, install it on your device and browsers, generate certificates using the CA, use those certificates in your server — all manual, all error-prone [1]. Tecmint’s mkcert guide puts it plainly: “Generating a self-signed certificate, getting your browser to trust it, and dealing with the warnings can be a real pain” [3].

mkcert solves all of that with mkcert -install and mkcert localhost 127.0.0.1. mkcert Web UI solves the next problem: you’re running multiple services, you can’t remember what certs you’ve already created or where you saved them, and you’re SSH’d into a machine that doesn’t have a graphical terminal handy [2].

The SCEP angle matters for homelab setups. Modern iOS and macOS devices support SCEP for automatic certificate enrollment — meaning your phone can automatically trust your internal CA without you manually installing profiles. The web UI includes a full SCEP server with challenge-password authentication [README]. That’s not something you get from the bare mkcert CLI, and it’s nontrivial to set up from scratch.

Self-signed certs are a solved problem for public sites (Let’s Encrypt handles that), but local development environments and air-gapped internal networks still need a path to trusted HTTPS. For a homelab with Proxmox, TrueNAS, self-hosted dashboards, or a home AI server, a local CA is the cleanest solution. One homelab operator noted in a home AI server write-up that SSL was a prerequisite to add a progressive web app to the iOS home screen — a real constraint that forces the certificate question for anyone running internal services [4].

---

Features

Based on the README and source review:

Certificate generation:

• Generate certificates for multiple domains and IP addresses from the browser [README]
• Wildcard certificate support [2]
• Output in PEM, CRT, or PFX (PKCS#12) formats [README]
• View existing certificates with expiration dates and subject info [2]
• Archive/restore certificate management [README]

SCEP server:

• Built-in SCEP for automatic device enrollment on iOS, macOS, Windows [README]
• Time-limited challenge password authentication [README]
• Implements GetCACert and GetCACaps operations [README]
• Dedicated /scep.html management interface [README]

Authentication:

• Basic username/password auth (default: admin/admin — change this) [README]
• OpenID Connect (OIDC) SSO support [README]
• Session-based auth with configurable secrets [README]

Monitoring and alerts:

• Automated certificate expiry monitoring via cron [README]
• Configurable warning periods (30-day and 7-day thresholds by default) [README]
• SMTP email notifications with support for Gmail, Outlook, and Exchange [README]

Security hardening:

• Allowlist-based command injection protection (critical for anything shelling out to CLI) [README]
• Path traversal prevention [README]
• Multi-tier rate limiting: 10 CLI ops/15min, 100 API calls/15min, 5 auth attempts/15min [README]

REST API:

• /api/generate for certificate creation [README]
• /api/certificates for listing [README]
• /api/monitoring/expiring for expiry status [README]
• Standard download endpoints [README]

Deployment:

• Docker Hub image available [README]
• docker-compose included [README]
• Systemd service file included for non-Docker installs [README]
• HTTPS mode available on a separate port (3443 by default) [README]

---

Pricing: SaaS vs self-hosted math

This tool doesn’t have a SaaS equivalent — there’s no subscription to escape. The comparison that matters is time cost vs. alternative approaches.

Option 1: mkcert CLI directly

• Software cost: $0 (Apache 2.0 license)
• Ongoing cost: memorizing mkcert -key-file key.pem -cert-file cert.pem example.com *.example.com and tracking where you saved things
• Works fine if you touch certificates once a month and have decent notes

Option 2: mkcert Web UI

• Software cost: $0 (GPL-3.0)
• Hosting cost: runs fine on a $5–6/mo VPS or inside your existing homelab
• Setup time: 15–30 minutes with Docker
• Ongoing benefit: browser-based cert generation, expiry alerts, SCEP enrollment, no flag-memorizing

Option 3: Commercial certificate management

• Tools like HashiCorp Vault handle PKI at scale, but that’s serious infrastructure overhead for a homelab
• For public-facing services, Let’s Encrypt via Caddy or Traefik is free and automatic — mkcert is specifically for internal/local use where Let’s Encrypt can’t validate

The honest math: if you manage fewer than 10 local certificates and touch them rarely, the CLI is fine. If you’re running a homelab with a dozen services, mobile devices that need trusted access, or a small team where more than one person needs to generate certificates, the web UI pays for itself in the first hour.

---

Deployment reality check

The installation is straightforward if you’re already running Docker. The project ships a docker-compose.yml and a Docker Hub image:

git clone https://github.com/jeffcaldwellca/mkcertWeb.git
cd mkcertWeb
docker-compose up -d
# Access at http://localhost:3000

The non-Docker path requires Node.js 16+, mkcert installed on the host, and OpenSSL — which is fine for a development machine, less ideal for a headless server where you want clean dependency management.

What to watch out for:

The default credentials are admin/admin. This isn’t theoretical — the README documents it plainly in the Usage section [README]. Change AUTH_USERNAME, AUTH_PASSWORD, and SESSION_SECRET before you expose this to any network.

The app shells out to mkcert for certificate operations. The README documents command injection protection via allowlist validation, but you’re still running user-supplied domain names through a CLI command. The rate limiting (10 CLI operations per 15 minutes) is a reasonable mitigation, but this is one of those security surfaces worth reviewing if you’re exposing it beyond localhost [README].

SCEP setup is more involved than the base app — there’s a separate SCEP.md in the repository. If you need automatic iOS enrollment, budget extra time.

The project has 78 commits total and 9 forks. That’s thin for a tool handling certificate operations. There’s no public issue tracker discussion of security audits, and the “enterprise-grade security” language in the README is the maintainer’s own characterization. Trust it proportionally.

Realistic time estimates:

• Docker-comfortable homelab operator: 15–30 minutes to a working instance
• Developer following the README on a fresh VPS: 30–60 minutes including SMTP setup
• Non-technical user: this is probably not the right tool — the CLI it wraps requires prior system installation

---

Pros and Cons

Pros

• Eliminates terminal friction for mkcert. If you already use mkcert and hate re-typing the flags, this is exactly what the creator built it for [2].
• SCEP server included. Automatic iOS/macOS device enrollment in a single container is genuinely useful and not trivial to set up otherwise [README].
• Email expiry monitoring. Certificates you generate and forget are a real problem — automated 30-day and 7-day alerts catch this [README].
• OIDC SSO support. For a homelab, being able to put this behind your existing identity provider (Authentik, Keycloak, etc.) is a significant convenience [README].
• Docker-ready with a public image. The fastest path to running it is docker-compose up [README].
• REST API. If you want to automate certificate generation from scripts or CI, the API surface covers the basics [README].
• Rate limiting and command injection protection are present. For a tool that shells out to CLI, these are the right instincts — whether the implementation is exhaustive is unverified [README].

Cons

• 206 stars and 9 forks. Small projects run by a single person disappear. If this project goes unmaintained, you own the Node.js code and the mkcert dependency [GitHub].
• GPL-3.0 license. Unlike the MIT-licensed mkcert CLI, the web UI’s GPL-3.0 license means embedding it in a commercial product requires open-sourcing your product. Irrelevant for personal use; relevant for anyone building a managed homelab service around it.
• No independent security audit. The README claims enterprise-grade protection, but there are no published CVEs, no security researchers who’ve reviewed it, no track record. For anything handling certificate operations, this deserves skepticism [README].
• Default credentials are admin/admin. Obvious but worth calling out — the path from “I’ll set it up and configure later” to “exposed to my local network with default creds” is short [README].
• Thin documentation on edge cases. The SCEP setup is in a separate markdown file with no community Q&A to fill gaps. When something breaks, you’re on your own [README].
• Mkcert must be pre-installed. The web UI doesn’t bundle mkcert — you install it separately. Docker image handles this, but it means the security of your CA chain depends on how you handle the underlying mkcert setup [README].
• No audit log. There’s no record of who generated which certificate when. Fine for solo use; a gap if multiple people share the instance.

---

Who should use this / who shouldn’t

Use mkcert Web UI if:

• You’re a developer or homelabber who already relies on mkcert and wants a browser interface instead of a terminal.
• You’re managing several internal services that need HTTPS and want a central place to track certificate expiry.
• You need SCEP enrollment for iOS or macOS devices on your home network.
• You have other people in your household or team who need to generate development certificates but shouldn’t need CLI access.
• You’re comfortable with Docker and can do a 30-minute setup.

Skip it (use mkcert CLI directly) if:

• You generate certificates rarely and don’t mind the terminal.
• You need something audited for production security use — the raw mkcert CLI is simpler and better-understood.
• You want an MIT license for commercial embedding.

Skip it (use Caddy or Traefik with automatic Let’s Encrypt) if:

• Your services are publicly accessible. Let’s Encrypt handles real certificates for free, and Caddy’s automatic HTTPS requires zero manual certificate management.

Skip it (use HashiCorp Vault PKI) if:

• You’re managing certificate infrastructure at scale, need HSM backing, or need full audit trails. Vault’s PKI secrets engine is purpose-built for this; a Node.js wrapper around a CLI is not.

Skip it entirely if:

• You have no prior experience with certificates, certificate authorities, or self-hosted services. The tool assumes you understand what you’re doing — it won’t teach you the underlying concepts.

---

Alternatives worth considering

• mkcert CLI — the underlying tool this wraps. 60K+ GitHub stars, Apache 2.0 license, written by Filippo Valsorda (a security researcher), well-audited by the community. Use this if you’re comfortable with the terminal [1][3][5].
• Smallstep (step-ca) — a production-grade open-source certificate authority. ACME protocol support, SSH certificates, hardware security key integration. Substantially more complex to set up than mkcert Web UI, but built for organizations that take PKI seriously.
• HashiCorp Vault (PKI secrets engine) — enterprise-grade certificate authority management with full audit logs, HSM support, and fine-grained access control. Overkill for a homelab, appropriate for teams.
• XCA — a desktop GUI application for managing certificates. Works on Windows/macOS/Linux, no server required, open source (Apache 2.0). Good if you want a desktop app rather than a web service.
• Caddy with automatic HTTPS — if the goal is trusted HTTPS on your local network, Caddy’s automatic certificate management eliminates manual cert generation entirely for publicly routable domains.

---

Bottom line

mkcert Web UI is a useful quality-of-life wrapper for a developer tool that was already excellent. If you use mkcert, keep forgetting flags, and want expiry alerts and SCEP enrollment without writing the plumbing yourself, this delivers. The SCEP support in particular is a genuine value-add that would take significant effort to build from scratch.

The caveats are proportional to the project’s size: 206 stars, one maintainer, no published security audits, GPL-3.0 license, and default credentials that need changing immediately. This is not infrastructure you’d put between untrusted networks and sensitive certificate operations. For a homelab or a developer workstation, those trade-offs are fine. For anything customer-facing, look at step-ca or Vault instead.

The underlying mkcert CLI remains the more trustworthy choice for anyone who doesn’t specifically need the web interface — but for the people who do need it, this project solves the problem it was built for.

---

Sources

1. Shriram Sharma, Medium — “mkcert, you changed my life!!” (Jun 20, 2019). https://medium.com/@shriramsharma/mkcert-you-changed-my-life-b157466880bf

2. r/selfhosted — u/comdak — “mkcertWeb - a web UI for mkcert”. https://www.reddit.com/r/selfhosted/comments/1m9ca71/mkcertweb_a_web_ui_for_mkcert/

3. Tecmint — “mkcert: Create Trusted SSL Certificate for Local Development”. https://www.tecmint.com/mkcert-create-ssl-certs-for-local-development/

4. Shawn Hoover — “Running a Home AI Server With Open WebUI and AWS Bedrock”. https://shawnhoover.dev/notes/home-ai-server.html

5. Chocolatey Community — “mkcert 1.4.4 package”. https://community.chocolatey.org/packages/mkcert

Primary sources:

• GitHub repository and README: https://github.com/jeffcaldwellca/mkcertWeb (206 stars, GPL-3.0)
• Docker Hub image: https://hub.docker.com/r/jeffcaldwellca/mkcertweb