ACME-HTML-Web-Browser-Client issues TLS certificates from a single HTML file

One HTML file as an ACME client

The ACME Web Browser Client is described as a single static HTML web page file whose only purpose is to apply for free SSL/TLS domain certificates for HTTPS from certificate authorities that support the ACME protocol, naming Let's Encrypt, ZeroSSL and Google explicitly. The design constraint that shapes everything is that the whole client is one file with no dependencies. The documentation claims no operating system restrictions, no running environment to consider, and no need to download and install software, since you open the page in the browser you already use. It also states that the client does not require registering an account and does not require logging in. The project is published under the GPL-3.0 licence, the repository holds the HTML file, the licence, the README and two screenshots, and the primary language is recorded as HTML. The online version is served from a GitHub Pages site, and the same file can be saved locally and opened directly from disk.

The six steps of the certificate request

The usage documentation walks through a fixed sequence, and reading it tells you what the tool automates and what it leaves to you. First you open the client, either by double clicking the local HTML file or by opening the online page. Then step one is choosing a certificate authority in the page or entering a supported ACME service address, with the note that different authorities need different operations. Step two is filling in the domain names, where multiple domains, wildcards and IP addresses are supported, along with the key configuration. Step three is the part you do by hand, configuring an ownership verification method for each domain, and the common methods listed are a TXT record in DNS and uploading a file to the server, with the note that wildcard domains generally support DNS verification only. Step four is waiting for validation to pass, after which the page shows the certificate for download. The last step is configuring the downloaded certificate and private key on your own web server, and the documentation is candid that the configuration method differs per server program and is left to you. So the tool covers the protocol and the key handling, and leaves DNS and web server configuration to you.

What the page supports: key types, domains and IP addresses

The feature list is written in a bilingual form where the Chinese original carries some of the emphasis, and the English summary makes the scope clear. On key types, the client applies for either RSA or ECC, also written as ECDSA, certificates. On names, it supports multiple domain names in one request, wildcard names, and IP certificates where the authority offers them, with both IPv4 and IPv6 mentioned. On authorities, several are supported, and the topics on the repository list acme-client, certificate, lets-encrypt, zerossl and goog-pki, which lines up with the three named providers and the reference to Google PKI. The distinction that matters when you pick an authority is that the required steps differ between them. The documentation repeats this in each of the four steps, warning that the operations required by different certificate authorities may not be the same, and instructing you to follow the prompts rather than a fixed procedure. That is not boilerplate. A client that works identically against every authority would be a different design, and the fact that the page is interactive and prompt-driven is what lets it adapt.

The data and system security claims, and what they mean

Two of the feature bullets are about safety rather than function, and they are the ones worth interrogating. The data security claim is that except for the ACME interface address of the certificate authority you specify, the web client will not send data to any other address, and that it is easy to check the network traffic through the browser console. That is a checkable claim rather than a marketing one, because the browser devtools network panel shows every request the page makes, so a user can verify it for themselves rather than take it on trust. The system security claim is that as a pure web application it will not and cannot make any modification to your computer system, which follows from the same architecture. The honest caveat is on the other side of that. A page that asks you to paste a private key, and that you then use to sign a certificate request, is a page handling a credential, and the protection is the browser's own isolation plus your own judgement about where you downloaded the file from. The project publishes its own hosted copy and a source repository, and those are the two places the file should come from.

No automatic renewal, which is the real limitation

The documentation puts a certificate expiration risk alert near the top, and it is the most important thing on the page. Since the web client can only be operated manually and does not support automatic renewal, you should apply for a new certificate before the current one expires, and the note observes that free certificates are generally valid for 90 days, so the operation only has to be repeated at that point. The suggested alternative for anyone who wants automation is acme.sh and other clients with automatic renewal. That is a substantial difference in kind rather than degree. A conventional ACME client runs on a server, holds the account key, installs a renewal timer and reloads your web server when a certificate rotates, and it never asks a human to paste anything. This client inverts all of that: it makes the process possible without a server, at the cost of making the recurring part manual. For a one-off certificate on a machine you are sitting in front of, that trade is good. For a production site, it is the wrong shape, because a missed renewal is an outage, and the failure mode is silent until a browser shows a certificate error to your users.

How this compares with a real ACME client

The obvious alternative is an established command line client such as acme.sh, certbot, or the win-acme tooling on Windows, and the difference in approach is what decides the fit. A conventional client is a long running installation on the machine that serves the site, it owns the account registration and the private key on disk, it can solve challenges automatically, either with DNS hooks or by serving the challenge itself, and it schedules renewal. This page owns nothing and persists nothing. It runs inside a browser tab, it holds the key in memory for the length of the session, and the only thing it produces is a PEM file you download and place yourself. The second difference is the trust boundary. A local client talks to the certificate authority from your own machine, with your own DNS credentials and your own storage. A page in a browser talks to the authority from wherever the page is running, and a page served from a hosting site is code you did not build executing with your domain and your key in scope. The third difference is repeatability. A scheduled client is idempotent and produces the same result unattended every 60 days. A manual page requires you to remember.

Where the project sits and who maintains it

The project is published under the GPL-3.0 licence, with the licence file in the repository root alongside the HTML client and the two screenshots, one in Chinese and one in English. Support is offered through two QQ groups, with a password required to join, and the author invites requests for custom work including websites, apps, mini programs and front end and back end development through those groups. That is the whole of the support model, and for a tool that handles private keys it is worth knowing before you start. The release history shows a version numbering scheme that encodes the date, with 1.0.260705 on 2026-07-05, 1.0.260120 on 2026-01-20 and 1.0.240804 on 2024-08-04, and the last push to the repository was on 2026-07-05. There is a README section on some of the underlying principles, and the repository also mirrors onto Gitee, which is the usual arrangement for a project that wants a reachable mirror. The primary language being HTML is not a simplification here, it is the point: the entire client is a document.

Editorial conclusion

Adopt ACME-HTML-Web-Browser-Client if you need a certificate now, on a machine where you cannot or do not want to install a client, and you are comfortable driving DNS records by hand for the validation step. Do not adopt it for anything that has to renew on a schedule, because the documentation states plainly that the client is manual only and does not support automatic renewal, and free certificates generally last about 90 days. Verify two things before you rely on it: that you have a way to add the DNS TXT record or the validation file the page asks for, since that is the step that decides whether the request succeeds, and that you understand the private key handling, because the key is generated and kept in the page and you are the one downloading and storing it. The practical first step is to open the online page, pick a certificate authority, and work through the four steps the interface presents.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xiangyuecn/ACME-HTML-Web-Browser-Client on GitHub