ACME (Automated Certificate Management Environment) clients come in two forms: browser-based (like GetHTTPS) and command-line (like Certbot and acme.sh). Both talk to the same Let’s Encrypt API and issue identical certificates. The difference is where the work happens and who controls the keys.
Comparison
| Browser-based (GetHTTPS) | CLI (Certbot, acme.sh) | |
|---|---|---|
| Where it runs | Your browser tab | Server command line |
| Installation | None | Required (snap, pip, shell script) |
| Key generation | Browser (Web Crypto API) | Server (OpenSSL) |
| Key storage | Downloaded by you | Server filesystem |
| Auto-renewal | ❌ Manual | ✅ Cron/systemd |
| Server access needed | No | Yes |
| GUI | ✅ | ❌ |
| Pre-check validation | ✅ (GetHTTPS) | ❌ |
| Scriptable | ❌ | ✅ |
| Dependencies | Modern browser | OpenSSL, curl, cron |
When browser-based wins
- No server access — shared hosting, managed platforms, or servers you can’t install software on
- Maximum key privacy — the private key exists only in browser memory until you download it
- Non-technical users — a web UI is more approachable than a terminal
- One-off certificates — faster than setting up a CLI tool for a single cert
- Helping others — easier to screen-share a browser flow than dictate CLI commands
When CLI wins
- Automated renewal — essential for production servers, especially with 47-day validity coming
- Infrastructure at scale — scriptable, containerizable, configurable via config management
- DNS API automation — CLI tools like acme.sh have plugins for 150+ DNS providers
- CI/CD integration — certificate issuance as part of deployment pipelines
- Server auto-configuration — Certbot’s Nginx/Apache plugins configure the server directly
The hybrid approach
Many teams use both:
- GetHTTPS for the first certificate (zero setup time)
- Certbot or acme.sh installed later for ongoing auto-renewal
This gets you running immediately without the upfront cost of setting up a CLI tool, then adds automation when you’re ready.
Browser-based ACME clients
The browser-based ACME client category is relatively new. Options include:
| Client | Open source | Key generation | Direct ACME | Pre-check |
|---|---|---|---|---|
| GetHTTPS | No | Browser (Web Crypto) | Yes | Yes |
| SSL For Free | No | ⚠️ Server-side | Via ZeroSSL | No |
| ZeroSSL Dashboard | No | ⚠️ May be server-side | Via ZeroSSL API | No |
GetHTTPS is the only browser-based client that generates keys locally using the Web Crypto API and connects directly to Let’s Encrypt’s ACME API without any middleware.
CLI ACME clients
The CLI ecosystem is more mature:
| Client | Language | Root needed | Auto-renewal | DNS plugins | Server config |
|---|---|---|---|---|---|
| Certbot | Python | Yes (snap/pip) | Yes (systemd) | Via plugins | Nginx/Apache auto-config |
| acme.sh | Shell | No | Yes (cron) | 150+ built-in | Manual |
| Lego | Go | No | Yes | 100+ | Manual |
| Caddy | Go | N/A (built-in) | Yes (automatic) | Via DNS modules | Built into Caddy server |
| dehydrated | Shell | No | Yes (cron) | Via hooks | Manual |
For detailed comparisons: GetHTTPS vs Certbot → | GetHTTPS vs acme.sh →
The future: 47-day certificates
With certificate validity dropping to 47 days by 2029, the balance shifts further toward CLI clients for production use. Renewing every 30-35 days manually (browser-based) is doable but tedious.
However, browser-based clients won’t disappear. They serve permanently useful niches:
- Environments without CLI access — shared hosting, managed platforms, restrictive corporate environments
- First-time setup — get HTTPS working in 5 minutes, then decide whether to install a CLI tool
- Emergency renewal — server’s Certbot broke and you need a cert NOW
- Certificate for someone else — generate a cert for a client or teammate without accessing their server
- Privacy-sensitive scenarios — the key should never exist on any server, even temporarily
Frequently asked questions
Is a browser-based client less secure?
Not inherently. GetHTTPS generates keys with the Web Crypto API (same cryptographic primitives that TLS itself uses) and communicates directly with Let’s Encrypt over HTTPS. The key never touches any third-party server. The main trade-off is the lack of automated renewal, not security.
Will browser-based clients become obsolete with 47-day certificates?
Not obsolete, but less convenient as a sole renewal method. They’ll remain valuable for initial setup, emergency renewals, and no-server-access scenarios. But for production workloads renewing every 30-40 days, CLI automation is the pragmatic long-term choice.
Which CLI client should I use?
Certbot if you want Nginx/Apache auto-configuration and don’t mind root access. acme.sh if you want no-root operation, DNS API plugins, and a lightweight footprint. Caddy if you’re switching web servers — it handles HTTPS automatically with zero configuration.
Can a browser-based client work for automated pipelines?
Not directly — browser-based clients require manual interaction. For CI/CD pipelines or infrastructure-as-code, use a CLI client. GetHTTPS is designed for human-operated workflows; Certbot and acme.sh are designed for machine-operated ones.