On this page

• Overview
• Two certificate sources
• Lifecycle
• Security model
• Automatic renewal
• CRL & public endpoints

Overview

TLS certificates are a nightmare at scale. One expired cert brings down a service; one forgotten renewal triggers an outage at 3am. ManageLM bakes a full PKI into the portal: pick a source (internal CA or Let's Encrypt), set a validity window, click New Certificate, and the agent on the target server handles the rest — CSR generation, file deployment, service reload.

The design principle is simple: the private key never leaves the agent. The portal sees only the CSR and the signed certificate. Key compromise is impossible in transit because the key never transits.

Two certificate sources

HTTP-01 is the default: the agent handles the challenge on port 80 automatically — ideal for public-facing servers. DNS-01 goes further: the portal talks to your DNS provider (Cloudflare, DigitalOcean, Hetzner, OVH) and validates via DNS TXT records, which means any agent can get a certificate — public, private, or firewalled — and wildcards like *.example.com are supported out of the box.

Lifecycle

1. Issue
   You pick an agent, a common name, and a file path. The agent generates a keypair and CSR locally. The portal validates, signs with the internal CA (or relays to Let's Encrypt via ACME), and streams only the signed cert back over WebSocket. The agent writes the cert + key to disk and reloads the target service.

2. Renew
   Manually with the Renew button, or automatically via the daily renewal sweep. Renewal mints a fresh keypair and CSR on the agent, signs a new cert, deploys it, then revokes the old one. LE renewals also notify Let's Encrypt to revoke the outgoing cert server-side.

3. Revoke
   Mark a certificate as revoked and the portal updates the CRL immediately. LE revocations propagate to Let's Encrypt's ACME endpoint. Internal CA revocations can be reactivated; LE revocations are final.

4. Delete
   Soft-deletes the certificate metadata. The serial stays in the CRL until the natural expiry date, at which point the daily sweep purges it.

Security model

• Transport — all portal ↔ agent traffic rides the existing mTLS-authenticated WebSocket connection. No separate channel, no side-deployed tooling.
• Signing material — internal CA private keys are stored AES-256-GCM encrypted at rest with account-scoped keys.
• Auditability — every issue / renew / revoke produces a portal audit log entry with user, agent, timestamp, and source IP.
• Role-based control — CA and LE account management is restricted to the account owner; the perm_certificates permission controls day-to-day operations.

Automatic renewal

A daily background task handles the entire certificate lifecycle without human involvement. It is Redis-locked for high availability (safe for the DNS round-robin portal pair) and runs through four stages:

1. Expire certificates whose not_after has passed.
2. Renew active certificates inside the renewal window (7–90 days before expiry, configurable), but only on online agents.
3. Purge soft-deleted certificates whose serial has naturally expired.
4. Notify admins via in-app, email, and webhook on renewal success or failure.

Configure the default validity (14–365 days), key type, and renewal window once in Settings → PKI & CA. New certificates inherit the defaults — no per-cert boilerplate.

CRL & public endpoints

The portal exposes two unauthenticated endpoints used by TLS clients and auditors:

Both URLs are embedded in every issued certificate as CRL Distribution Point and Authority Information Access extensions — so TLS clients can fetch trust and revocation data without extra configuration.