httpsok and the shell script that renews certificates for you

A script plus a console, not a standalone tool

httpsok is presented as a convenient HTTPS certificate automatic renewal tool, built on a new design idea, designed for servers running Nginx, OpenResty or Apache. The claim in the project description is that one command sets up automatic certificate renewal in about a minute, and the feature list calls the tool simple and efficient, with automatic detection that means you do not need to care about the Nginx configuration, which the project says makes it suitable for old systems and complex production configurations.

The repository itself is tiny, which is the clearest signal of the design. The top level holds the shell script httpsok.sh, a docker/ directory, the licence file and three readmes, the Chinese one, an English one and a translated Chinese one. There is no library, no plugin architecture and no configuration schema in the tree.

The rest of the design lives on the vendor's side. The documentation is hosted at httpsok.com/doc/, and the installation step begins in a browser rather than in a terminal, because you log in to the web console to obtain the install command. After the script has run, the certificates it finds on the system are synchronised to that console, and the console is where you manage them, where the expiry alerts are configured, and where the DNS instructions for your case are given.

So the tool is best understood as a shell client for a hosted certificate management service. That framing decides what to expect. It is very easy to start, because a vendor has already written the issuance, storage and scheduling logic and you are running their script, and it is a smaller operational commitment than running your own ACME tooling, at the price of a dependency on someone else's control plane.

Three steps, and the second one is still manual

The quick start in the README is described as two steps, and the detail is in what they consist of.

The first is installation. You log in to the web console at httpsok.com/p/4c9n, obtain the installation command, and run it on the server. The command itself is not in the repository, which is a deliberate choice, since it presumably carries an account or installation identifier. After the installation succeeds, the script automatically detects the Nginx certificates present on the system once and synchronises them to the console.

The second is DNS configuration. The README says to add the corresponding DNS records according to the actual situation of the script run, and links a DNS configuration reference page. This is the step that cannot be automated away, because proving control of a domain for a wildcard certificate means creating a record, and the record to create depends on the challenge the service asks for. A certificate tool that promised to remove that step would be asking you to trust it with your domain in a way that no ACME client requires.

The third is finishing, which the README states with some economy: log in to the console and look at your certificates.

That is the whole flow, and it is genuinely short. The work is front loaded into the console, where the DNS record, the domains to cover and the servers to deploy to are configured once, and the shell script does the deployment and renewal on the hosts afterwards.

Wildcards, multiple domains, multiple servers and the cloud edges

The feature list is where the tool's actual scope appears, and it is broader than a plain certificate renewer.

Automatic detection is the first item and the most operationally useful one. The tool identifies the certificate configuration on the server by itself, which means you do not hand it a list of paths and server names, and the project frames that as the difference between a tool that works on a machine you configured and one that works on an old production box you inherited.

Wildcard domains, multiple domains and multiple servers are grouped as one capability, which covers the common Chinese hosting shape of one certificate deployed to several machines behind a load balancer. Support for CDN, LB and OSS is stated as being for mainstream cloud vendors, which matters because certificate deployment to a CDN is a different API from deployment to an Nginx host, and a tool that handles both removes a whole class of work from a release checklist.

Manual issuance is supported, which is what you want for a one-off certificate outside the renewal workflow, and the compatibility list names Debian, CentOS, Ubuntu, TencentOS and docker container environments. The container entry is worth noting, because a certificate that has to survive a container restart needs a different deployment story from one installed into a host's Nginx configuration.

Expiry monitoring is the quiet feature. The project says it pushes a notification through a WeChat public account for certificates that are about to expire, which is a real answer to the operational question of what happens when renewal silently stops working at three in the morning.

What it is not, and where the dependency sits

The project description positions the tool as a way to stop using Let's Encrypt, and that framing deserves a careful reading, because the difference is architectural rather than cosmetic.

A certificate renewal tool that you run yourself talks to a certificate authority directly, holds its own credentials, and has no service in the middle. httpsok instead runs a vendor script on your host, and the issuance, the record of which certificates you hold, the renewal schedule and the alerting all live in the vendor's console. The shell script is the deployment and renewal agent, not the authority.

The practical consequences follow from that. Your certificate lifecycle depends on the vendor's console being reachable and behaving, so the tool cannot be used in an environment where a third party service is not acceptable, and the domain's DNS is still under your control, which is what makes the arrangement workable at all. The alternative is an ACME client you install and schedule yourself, which takes more initial work and a cron entry per host, and keeps the whole process inside your own estate with no control plane to depend on.

The other limitation is the one every script-based installer has. You are told to copy a command from a web console and run it on a server, and that command will need the privileges to install into Nginx configuration directories, to reload the server and, in the container case, to touch mounted configuration. The README does not describe what that command contains, and the reasonable advice to a cautious operator is to read it before running it, especially since the tool's own documentation lives on a domain that is separate from the repository.

One script, three readmes, and a service behind it

The repository contents are worth a second look because they describe the division of labour precisely. There is httpsok.sh, which is the part that runs on your server. There is a docker/ directory, for the containerised deployment path that the feature list mentions. There is LICENSE, and three readme files, README.md, README.en.md and README.zh.md, which is a sign that the tool is used in more than one language community.

Everything else is documentation hosted elsewhere. The feature list, the quick start, the DNS reference at httpsok.com/doc/guide/dns.html, the console itself, and the video walkthroughs that the readme embeds as hosted assets. The contact route is also unusual and worth noting for anyone evaluating it: the feedback section asks readers to reach the author on WeChat with the word httpsok in the message, and shows a QR code.

That is a coherent picture of a project that is a thin local agent around a hosted product. The MIT licence applies to the code in the repository, which is the shell script and the docker assets, and the service itself is not covered by it. An organisation evaluating this has to treat the two as separate things, one you can read and fork, and one you use.

MIT, and a release history that has slowed

The licence is MIT, with the licence text in the LICENSE file at the root, and the badge in the readme agrees. For a shell script that installs into web servers, MIT is the expected choice and requires only that the copyright and licence notice be kept.

The release history is the part to note. The recent tags are v1.18.2 on 2025-09-16, v1.18.0 on 2024-12-07 and v1.17.0 on 2024-09-28. So the last published release is over a year old, and the gaps between the earlier tags are between about two and nine months, which is the rhythm of a project that releases when there is something to release rather than on a schedule.

The repository is not archived, and the last push was on 2026-05-25, which is five months before the current state of the project and well after the last tag. So the script in the repository is newer than the version most people installed, which is normal for a script that is fetched by the console rather than by a version manager.

The version badge in the readme still reads 1.18.2, matching the newest tag, which is a useful signal that the file and the tag have not drifted in the documentation. For an adopter the practical advice is narrow and specific: check what the console actually installs on your host, since that is the artefact that runs, and pin or record it if you need the deployment to be reproducible across a fleet.

Editorial conclusion

Adopt httpsok if you run Nginx, OpenResty or Apache servers behind Chinese cloud providers and want certificate renewal without wiring ACME yourself or running a cron job per host. Do not adopt it if your requirement is a self-contained renewal process, because the tool is a client of a hosted console and the certificate lifecycle depends on that service staying available, and do not adopt it in an environment where a vendor script cannot be run with the privileges it needs. Verify three things first: that your DNS provider is supported by the console, since the DNS records are the part you still have to add yourself, that the certificates currently on the host are detected correctly before the first renewal, and that the expiry alerts reach a channel someone actually watches. The last push was on 2026-05-25 and the newest release is v1.18.2 from 2025-09-16.

Frequently asked questions

Official sources

1. httpsok/httpsok on GitHub
2. License: MIT
3. Project website
4. README
5. Releases