CertMate: Self-Hosted TLS Certificate Lifecycle Management

CertMate's Certificate Inventory and Delivery Scope

CertMate targets organizations whose TLS certificates are spread across applications, hosts, and infrastructure components. Its stated scope goes beyond obtaining a public certificate. The platform can discover certificates that it did not issue, place certificates and serving locations in one inventory, record issuers and expiration dates, and deploy renewed files where an application expects them. This is useful for operators who need one place to answer which certificate is active, where it is served, and when it expires.

The audience includes administrators of distributed services, platform teams, and organizations managing certificates across multiple data centers. Public issuance is not its only use case. CertMate also runs a private CA for internal names, supports mTLS as a topic associated with the broader product ecosystem, and offers certificate revocation lists. The README describes a REST API shared by the web interface, command-line clients, and Model Context Protocol server.

That breadth changes the evaluation. A certificate tool used only to create one ACME order is a different category from a service intended to own inventory and delivery workflows. CertMate makes sense when the inventory problem and repeated deployment work are large enough to justify a hosted control plane. Its documented capabilities do not remove the need to configure DNS access, certificate storage, authentication, and the target-specific delivery mechanism.

ACME, Private CA, and Discovery Data Flow

CertMate's primary Python stack includes Flask for the web application, Flask-CORS, flask-restx for the REST API, and Certbot with ACME and DNS provider plugins. The dependency file pins Certbot, ACME, josepy, and several provider packages as a coordinated family. Cloudflare, Route 53, DigitalOcean, and Google have dedicated `certbot-dns-*` dependencies. Azure DNS is handled differently: CertMate uses its own hook in `modules/core/azure_dns_hook.py`, because the listed `certbot-dns-azure` release does not support Certbot 4 or later.

A public certificate flow therefore begins with a domain and provider selection, creates the DNS challenge needed for ACME validation, and records the resulting certificate in CertMate's inventory. The README also describes renewal and deployment operations. Its private CA support extends the same management surface to internal names instead of requiring every internal endpoint to depend on a public CA.

Discovery is the more distinctive path. A deployment can contain certificates issued outside CertMate, and the project states that it discovers and inventories those too. The inventory model records where a certificate is served, who issued it, when it expires, and which cryptography it uses. The README does not specify scanner protocols or deployment adapters in detail, so the network permissions and host-level access required for discovery or file deployment should be checked before production use.

Installing the CertMate CLI and Running a First Request

The README provides a first use path through the separately published `certmate-cli` package. This is the shortest documented connection to an existing CertMate deployment. The commands assume that the web service is already available at `CERTMATE_URL`; the README does not show a complete server startup command in the visible Quick Start excerpt.

Install the CLI and point it at the service. A token may be omitted for a fresh instance that is still in setup mode.

pip install certmate-cli

export CERTMATE_URL=https://certmate.example.com
export CERTMATE_TOKEN=...

The next command checks connectivity. It should return the health response defined by the target CertMate server.

certmate health

After confirming connectivity, create a certificate for one named domain. The README describes `--dns cloudflare` as a DNS-01 issuance example, while `--wait` blocks until the operation is live. Relevant DNS credentials must already be available to the server.

certmate cert create app.example.com --dns cloudflare --wait

List the resulting inventory and inspect the named certificate. The second command should show the certificate data retained by that deployment.

certmate cert ls
certmate cert info app.example.com

The CLI also exposes an audit verification command. Its use is separate from certificate creation and checks the server's tamper-evident audit chain through the API.

certmate audit verify

Docker Deployment Boundaries and Initial Configuration

The repository provides a multi-stage `Dockerfile`, `docker-compose.yml`, Helm charts, a systemd service file, and nginx configuration examples. This gives operators several deployment paths, but the repository files do not present them as interchangeable. The Docker image defaults to Python 3.12 and supports selecting a smaller requirements file or layering optional provider and storage dependencies at build time.

The Compose service binds port 8000 only to localhost and expects the reverse-proxy arrangement to be configured separately. Production-oriented secrets include `SECRET_KEY` and `API_BEARER_TOKEN`. Both can be empty in the Compose template and auto-generated by the application, but the file comments advise setting strong production values. `BEHIND_PROXY` also needs an accurate value because proxy headers can influence how a client address is interpreted.

The visible Compose excerpt does not include the command that starts the service, so this article does not invent a `docker compose up` variant or claim that a minimal deployment is complete. The operator must consult the repository's installation section for the exact startup sequence and required environment variables. One concrete risk is already visible: exposing the service through a proxy without consistent `SECRET_KEY`, bearer-token, trusted-proxy, and TLS settings can leave the management plane inadequately protected.

REST API and MCP Access Boundaries

CertMate presents one server-side control plane through several clients. The Python `certmate-cli` is a thin client over `certmate-sdk`, which uses `httpx` to call the same REST API used by the web UI and MCP server. This is preferable to maintaining separate automation against undocumented interfaces, but it also means access control must be evaluated at the API layer.

The first-party MCP server is a Node.js component requiring Node.js 20 or later. Its documented installation is limited to installing dependencies in the `mcp` directory. The client configuration launches `mcp/index.js` and supplies `CERTMATE_URL` plus `CERTMATE_TOKEN`. The README lists 16 tools, including listing certificates, retrieving status and activity, creating or renewing certificates, checking jobs, enabling automatic renewal, downloading a certificate, and deploying it.

For agent access, the README explicitly recommends a scoped key with `is_agent: true`, rather than an administrator token. Such a key records actions as `actor.kind="agent"` in the audit trail and can be restricted to permitted domains. This is a meaningful separation of duties, although it does not remove the need to review the permissions of each individual MCP tool.

Maintenance, Storage Choices, and License Boundaries

The repository is not archived, and its last push was on 2026-10-15. Releases v2.48.4, v2.48.5, and v2.48.6 were published on 2026-10-06, 2026-10-08, and 2026-10-14 respectively. Those dates show recent project activity. They do not establish that every provider, storage backend, or deployment adapter is equally mature, so upgrades still require environment-specific checks.

The dependency model creates deliberate upgrade work. CertMate states that Certbot, ACME, josepy, and official DNS plugins must move together. Provider plugin constraints can otherwise reject installation or force inconsistent versions. Optional requirement sets exist for cloud and storage integrations, including AWS, Azure, GCP, Infisical, Vault, and a combined storage set. Operators need to identify which extras their environment needs and keep their selected image variant aligned with the corresponding pinned dependencies.

CertMate is licensed under the MIT License. The README separately advertises CertMate-ng for multi-tenant, mTLS, white-label, and NIS2-aligned enterprise deployments under BSL 1.1. That distinction matters when reviewing feature expectations: those enterprise capabilities are described as part of a source-available offering, not as unconditional features of the MIT-licensed repository.

Where CertMate Is the Wrong Tool

CertMate is a poor fit for a single host that only needs scheduled public certificate renewal. Adding a Flask control plane, REST API, inventory database, authentication, audit chain, and deployment integrations creates more configuration and failure points than a narrowly scoped ACME invocation. The README does not document rollback for failed certificate delivery, nor does it specify automatic recovery behavior for every deployment target. Those omissions should not be filled with assumptions.

Provider compatibility is another boundary. Although the project states support for 29 DNS providers, the visible dependency file shows special treatment for several major services and a custom Azure DNS hook. A provider marked as supported may still require credentials, API permissions, network access, or package variants that are absent from a minimal build. Likewise, certificate inventory does not replace monitoring every endpoint's effective chain, hostname coverage, protocol configuration, or trust-store behavior.

A direct Certbot setup remains the practical alternative for operators who only need issuance and renewal against one or a few supported DNS providers. It keeps the workflow close to the ACME client and avoids introducing CertMate's server and inventory layer. CertMate becomes relevant when the added control plane removes real coordination work across providers, private CAs, unknown endpoints, and deployment destinations.

Editorial conclusion

Adopt CertMate when an organization wants certificate operations hosted under its own control and already has DNS, storage, reverse-proxy, and deployment integrations to manage. Do not choose it as a lightweight replacement for a command-line ACME client when inventory, private CA services, audit records, and multi-target delivery are unnecessary. Before adoption, verify that the pinned Certbot provider family supports every required DNS environment, that the chosen storage backend preserves existing certificate material, and that a non-administrator API key can be restricted to the intended domains.

Frequently asked questions

Official sources

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