Stop Paying $100K for TLS Automation: certctl Does It Free

Stop Paying $100K for TLS Automation: certctl Does It Free

What if your TLS certificates expired overnight? Not a hypothetical nightmare — it happened to Microsoft Teams in 2020, to LinkedIn's cert in 2021, to countless smaller services that never made headlines. Each outage cost millions in revenue, reputation damage, and frantic 3 AM war rooms. Now here's the gut punch: the CA/Browser Forum just voted to cap public TLS certificates at 47 days by 2029. That's not a typo. Forty-seven days. For a team managing 100 certificates, that's 7+ renewals every single week, forever. Manual workflows aren't just risky anymore — they're mathematically impossible.

But wait. Before you resign yourself to a six-figure enterprise CLM contract with professional services billed at $400/hour, there's a secret weapon the infrastructure elite are quietly deploying. It's called certctl, and it's about to make you very angry at every dollar you've ever spent on certificate management.

What is certctl?

certctl is a self-hosted platform that automates the entire TLS certificate lifecycle — issuance, renewal, deployment, revocation, and alerting — with zero human intervention. Born from the frustration of watching teams stitch together cron jobs, custom scripts, and overpriced commercial tools, certctl delivers enterprise-grade certificate lifecycle management (CLM) without the enterprise-grade invoice.

Created by shankar0123 and actively maintained with weekly releases, certctl ships under the Business Source License 1.1 — source-available, free to use, modify, and self-host. The one restriction? You can't resell its certificate management as a commercial service to third parties. For everyone else running their own infrastructure, it's effectively open-source freedom without the six-figure price tag.

Why it's trending now: The convergence of Ballot SC-081v3's aggressive validity reduction timeline and a broader industry rebellion against vendor lock-in has created perfect conditions. Platform engineers are exhausted by tools that handle 60% of the problem and charge 400% of the value. certctl's promise — 12 native CA connectors, 15 deployment targets, complete audit trails, OIDC SSO, and private keys that never leave your infrastructure — hits every pain point simultaneously.

The project is currently in early-access, actively seeking design partners. But don't let that label fool you: the certificate lifecycle core is production-quality today, with RBAC, four-eyes approval, and agent-mode key generation that keeps secrets where they belong — on your hosts, not in some vendor's cloud.

Key Features That Make certctl Insane

certctl isn't a certificate tool. It's a certificate operating system. Here's what separates it from everything else on the market:

Universal CA Connectivity — Twelve native issuer connectors cover every scenario: Let's Encrypt and any ACME provider, embedded ACME/SCEP/EST servers for client compatibility, built-in local CA with sub-CA chaining under enterprise roots (hello, Active Directory Certificate Services), Smallstep step-ca, HashiCorp Vault PKI, EJBCA, AWS^{↗ Bright Coding Blog} ACM PCA, Google CAS, and commercial CAs including DigiCert, Sectigo, GlobalSign, and Entrust. Custom CA? The OpenSSL/shell-script adapter handles anything else.

Military-Grade Key Security — In agent-keygen mode (the production default), agents generate ECDSA P-256 keys locally and poll for work. Private keys never traverse the network, never touch the control plane, never exist where an attacker could bulk-exfiltrate them. The server-side keygen mode (CERTCTL_KEYGEN_MODE=server) is explicitly demo-only and refuses to boot without CERTCTL_DEMO_MODE_ACK=true — a fail-closed guard against accidental security degradation.

Fifteen Deployment Targets — NGINX, Apache, HAProxy, Caddy, Traefik, Envoy, IIS, Windows Certificate Store, Java keystore, AWS ACM, Azure Key Vault, SSH known-hosts, Postfix + Dovecot, F5 BIG-IP, plus Kubernetes Secrets (preview). File-based targets get atomic writes with SHA-256 idempotency, automatic rollback on failure, and per-target Prometheus counters. Shell commands are validated against metacharacter injection before execution.

Protocol Server Modes — Run certctl as an ACME server (RFC 8555 + RFC 9773 ARI with key rollover and revocation), SCEP server (RFC 8894 for Intune/ChromeOS/network appliances), or EST server (RFC 9266 with channel binding for 802.1X and IoT). Existing cert-manager, certbot, and lego clients connect transparently.

Enterprise Identity & Governance — OIDC SSO with per-IdP runbooks for Keycloak, Authentik, Okta, Auth0, Microsoft Entra ID, and Google Workspace. Seven RBAC roles with global/per-profile/per-issuer scope. Four-eyes approval for high-stakes issuance. Auditor split — regulator accounts can read audit trails and nothing else. Argon2id break-glass admin for SSO outage recovery. Every API call hits an immutable audit trail with actor attribution, body hash, and latency tracking.

AI-Native Operations — The bundled MCP (Model Context Protocol) server exposes 162 tools covering 221 REST API routes. Ask your AI client natural language questions: "Show me all expiring certificates" — "Revoke the VPN cert, key compromised" — "What agents are offline?" — and watch it translate to precise API calls. No extra attack surface; same authentication as REST.

Use Cases Where certctl Absolutely Dominates

The 47-Day Renewal Avalanche

You're managing 200 certificates across hybrid infrastructure. Ballot SC-081v3 just turned your quarterly renewal sprint into a perpetual weekly emergency. certctl's scheduler handles automated renewal with configurable windows, failure retry with exponential backoff, and deployment orchestration across all 15 target types. Sleep through March 2026. You've earned it.

Multi-Cloud, Multi-CA Chaos

Public sites use Let's Encrypt. Internal services need your corporate sub-CA chained under ADCS. IoT devices enroll via SCEP from Intune. Some legacy systems still need manual CSR workflows. Instead of maintaining four different tools with four different UIs and four different audit trails, certctl unifies everything in one control plane with consistent RBAC, alerting, and lifecycle visibility.

Compliance-Driven Environments

SOC 2, PCI-DSS, and FedRAMP auditors want proof that certificate issuance is gated, logged, and non-repudiable. certctl's four-eyes approval workflow, immutable audit trail with body hashes, auditor-role isolation, and CRL/OCSP revocation infrastructure satisfy these requirements without the $100K+ commercial CLM license.

Air-Gapped and High-Security Deployments

Private keys must never leave the hardware security module — or at minimum, never leave the host. certctl's agent-mode architecture with local key generation, pull-only deployment model (server never initiates outbound connections), and self-hosted control plane fits zero-trust and air-gapped environments that cloud-native CLM services cannot touch.

Platform Engineering at Scale

Your team runs Kubernetes, bare metal, VMs, and network appliances. You need certificate automation as a platform service that internal teams consume via API, not tickets. certctl's REST API, MCP server, Helm chart, and multi-tenancy RBAC let you offer "certificates-as-a-service" to engineering teams without building it yourself.

Step-by-Step Installation & Setup Guide

Docker^{↗ Bright Coding Blog} Compose (Recommended for Evaluation)

certctl provides a zero-config demo path that spins up a fully populated environment in ~30 seconds:

# Clone the repository
git clone https://github.com/certctl-io/certctl.git
cd certctl

# Launch demo environment with automatic setup
./deploy/demo-up.sh -d --build

The demo-up.sh wrapper is mandatory, not cosmetic. It exports a timestamped acknowledgement:

CERTCTL_DEMO_MODE_ACK_TS=$(date +%s)

This satisfies the Phase 2 SEC-H3 fail-closed guard in internal/config/config.go::Validate. Demo deployments must re-ACK every 24 hours — a forgotten demo container cannot silently serve production traffic with auth-type=none. The bare docker compose up command without this timestamp refuses to boot.

After launch, open https://localhost:8443. The demo seeds 180 days of realistic history across 13 issuers, 8 agents, managed and discovered certificates, jobs, deployments, audit events, and notifications. The certctl-tls-init container self-signs an ECDSA-P256 certificate on first boot — accept the browser warning for evaluation, or trust the generated ca.crt.

Production Docker Compose Deployment

For production, you must configure secrets explicitly — the fail-closed guards reject placeholder values:

# Copy and edit the environment template
cp .env.example deploy/.env
${EDITOR:-nano} deploy/.env

Set these five required secrets using openssl rand:

• POSTGRES_PASSWORD
• CERTCTL_AUTH_SECRET
• CERTCTL_API_KEY
• CERTCTL_CONFIG_ENCRYPTION_KEY
• CERTCTL_AGENT_ID

# Generate strong secrets
openssl rand -base64 32  # Use for each secret field

# Launch production stack
docker compose -f deploy/docker-compose.yml up -d --build

Verify health:

curl --cacert $(docker compose -f deploy/docker-compose.yml exec -T certctl-server cat /etc/certctl/tls/ca.crt) https://localhost:8443/health
# Expected: {"status":"healthy"}

Agent Installation (One-Liner)

Deploy agents across your fleet with automatic OS detection and service configuration:

# Install and start the agent
curl -sSL https://raw.githubusercontent.com/certctl-io/certctl/master/install-agent.sh | bash

This detects your OS and architecture, downloads the appropriate binary, configures systemd (Linux) or launchd (macOS), and starts the agent with secure defaults.

Kubernetes Deployment (Helm)

# Required values: TLS secret, API key, PostgreSQL↗ Bright Coding Blog password
# The chart fail-fasts at template time if any are missing
helm install certctl deploy/helm/certctl/ \
  --set server.tls.existingSecret=<your-kubernetes.io/tls-secret-name> \
  --set server.auth.apiKey=$(openssl rand -base64 32) \
  --set postgresql.auth.password=$(openssl rand -base64 32)

The production chart includes: Server Deployment, PostgreSQL StatefulSet (or external Postgres), Agent DaemonSet, health probes, read-only rootfs, dropped capabilities, non-root UIDs, optional PodDisruptionBudget, NetworkPolicy, Prometheus ServiceMonitor, and Ingress.

Container Images

# Pull latest signed and attested images
docker pull ghcr.io/certctl-io/certctl-server:latest
docker pull ghcr.io/certctl-io/certctl-agent:latest

Every release publishes Cosign keyless OIDC signatures, SLSA Level 3 provenance, and SPDX-JSON SBOMs.

REAL Code Examples from the Repository

Example 1: Demo Environment Launch Script

The demo-up.sh script embodies certctl's security-first philosophy — convenience without compromise:

#!/bin/bash
# deploy/demo-up.sh — Mandatory wrapper for demo deployments

# Export timestamped demo acknowledgement
# This satisfies Phase 2 SEC-H3 fail-closed guard
# Demo containers MUST re-ACK every 24 hours
export CERTCTL_DEMO_MODE_ACK_TS=$(date +%s)

# Forward all arguments to docker compose with demo overlay
docker compose -f docker-compose.yml -f docker-compose.demo.yml up "$@"

Why this matters: The timestamp export isn't bureaucracy — it's active security engineering. Without this script, internal/config/config.go::Validate detects a missing or stale acknowledgement and refuses to start. This prevents the classic "forgotten demo in production" vulnerability where evaluation configurations with weak authentication persist accidentally. The 24-hour expiration forces conscious, repeated consent to demo-mode posture.

Example 2: Health Check Verification

Production verification uses the self-signed CA certificate for trust establishment:

# Extract the auto-generated CA certificate from the server container
# and use it to verify the HTTPS health endpoint

curl --cacert $(
  docker compose -f deploy/docker-compose.yml exec -T certctl-server \
  cat /etc/certctl/tls/ca.crt
) https://localhost:8443/health

# Expected response: {"status":"healthy"}

Implementation insight: This pattern demonstrates certctl's TLS-everywhere architecture. Even internal health checks use HTTPS with TLS 1.3 pinned. The control plane refuses to boot if the TLS bundle is unusable — a fail-closed design that eliminates the temptation to disable TLS "just for now" in development environments that accidentally become production.

Example 3: Helm Installation with Required Secrets

helm install certctl deploy/helm/certctl/ \
  # Existing Kubernetes TLS secret for server termination
  --set server.tls.existingSecret=my-tls-secret \
  # 256-bit API key for service authentication
  --set server.auth.apiKey=$(openssl rand -base64 32) \
  # PostgreSQL credential — chart fails template if missing
  --set postgresql.auth.password=$(openssl rand -base64 32)

Security architecture: The Helm chart implements fail-fast validation at template time rather than runtime. Missing required values trigger immediate, explicit errors rather than deploying a broken system. The server.auth.apiKey uses 32 bytes (256 bits) of entropy from /dev/urandom via OpenSSL — substantially stronger than human-chosen passwords. Container-scope hardening includes read-only root filesystems, dropped Linux capabilities, and non-root UIDs, following defense-in-depth principles even when the orchestrator is compromised.

Example 4: Agent Installation Pipeline

# Single-command agent installation with automatic platform detection
curl -sSL https://raw.githubusercontent.com/certctl-io/certctl/master/install-agent.sh | bash

# The install-agent.sh script:
# 1. Detects OS (Linux/macOS) and architecture (amd64/arm64)
# 2. Downloads matching binary from GitHub releases
# 3. Verifies checksum if available
# 4. Installs to /usr/local/bin/certctl-agent
# 5. Generates local agent identity (ECDSA P-256 keypair)
# 6. Configures systemd/launchd service with auto-start
# 7. Starts agent and reports connection status

Critical security property: Step 5 generates keys locally on the target host. The private key never leaves the machine, never transits the network, never exists in the control plane's memory or storage. This is the fundamental architectural difference between certctl and cloud-native CLM services that require key escrow. Even a complete control plane compromise cannot bulk-exfiltrate private keys — attackers would need to compromise each agent individually.

Example 5: Makefile Development Workflow

# Build server and agent binaries from source
make build

# Execute full test suite with race detection
make test

# Run comprehensive linting: govet, staticcheck, contextcheck, unused
make lint

# Vulnerability scan against Go vulnerability database
govulncheck ./...

# Start local Docker Compose development stack
make docker-up

Quality assurance: CI enforces per-package coverage thresholds — service 70%, handler 75%, crypto 88%, auth packages 85-95%. These aren't aspirational targets; they're build-blocking gates. The .github/coverage-thresholds.yml file requires corresponding test work to lower any floor, preventing the common anti-pattern of coverage theater where thresholds are adjusted rather than achieved.

Advanced Usage & Best Practices

Agent-Mode Key Generation: Non-Negotiable — Never override CERTCTL_KEYGEN_MODE=server in production. The server-side keygen exists solely for CI testing and ephemeral demos. The CERTCTL_DEMO_MODE_ACK requirement isn't annoying — it's your insurance policy against accidental secret exfiltration.

Bootstrap Token Hygiene — The CERTCTL_BOOTSTRAP_TOKEN creates exactly one admin account, then permanently disables itself. Generate it with openssl rand -hex 32, use it immediately, and never store it in version control. This eliminates the persistent "setup backdoor" vulnerability common in self-hosted platforms.

RBAC Least-Privilege Design — Start with viewer for dashboard access, escalate to operator for routine operations, reserve admin for architectural changes. The auditor role is intentionally crippled — it reads audit trails and exports logs, nothing else. Use this for compliance reporting without granting certificate access.

Approval Workflows for High-Impact Profiles — Enable RequiresApproval on any certificate profile touching production load balancers, wildcard domains, or code-signing extensions. The two-person-integrity queue prevents both accidental misissuance and insider threats. Profile edits on approval-tier profiles route through the same gate — closing the "flip-flop bypass" where an attacker temporarily disables approval, acts, then re-enables.

Monitoring Integration — certctl exports per-target Prometheus counters for deployment success/failure/rollback. Alert on certctl_deploy_failed_total increasing — it indicates either target misconfiguration or credential expiration, often the first sign of broader infrastructure degradation.

IdP Resilience — Configure break-glass admin (CERTCTL_BREAKGLASS_ENABLED=true) with Argon2id hashing before production SSO cutover. Test the path quarterly. When your IdP has an outage at 2 AM on a holiday weekend, you'll be the hero with working admin access, not the person explaining why certificate renewal is blocked by Azure AD downtime.

Comparison with Alternatives

The verdict: Enterprise CLM platforms win on pre-built connectors for exotic legacy systems and formal support SLAs. cert-manager wins for pure Kubernetes-native environments. certbot wins for single-server Let's Encrypt automation. certctl dominates everywhere else — multi-CA, multi-target, compliance-gated, security-obsessed, budget-conscious infrastructure.

FAQ

Is certctl production-ready? The certificate lifecycle core (issuance, renewal, deployment, audit, RBAC) is production-quality today. The v2.1.0 federated identity layer (OIDC SSO) is actively seeking real-world IdP exposure. Lab and dev deployments are encouraged; production is welcome, especially for SSO battle-testing.

How does certctl handle the 47-day certificate validity? Automated renewal with configurable windows, failure retry with exponential backoff, and proactive alerting. The scheduler runs continuously — no cron jobs to maintain, no manual intervention required.

Can I use my existing ACME clients? Yes. certctl runs as a standards-compliant ACME server (RFC 8555 + RFC 9773 ARI). Point cert-manager, certbot, lego, or any ACME client at it transparently.

What happens if the certctl server is compromised? In agent-keygen mode (default), nothing to certificates. Private keys never exist on the server. The attacker gains metadata (what certs exist, when they expire) but cannot mint, decrypt, or exfiltrate private keys. This is architecturally impossible by design, not merely configured.

How do I migrate from certbot or acme.sh? Dedicated migration guides exist for both. The examples/acme-nginx/ and examples/acme-wildcard-dns01/ directories provide drop-in replacements with docker-compose configurations. cert-manager coexistence is documented for gradual migration.

Is there commercial support available? Currently community-supported via GitHub issues. The maintainer responds actively and ships weekly. For enterprise support inquiries, contact certctl@proton.me.

What databases are supported? PostgreSQL 16 with idempotent migrations. External Postgres is supported via Helm values for managed database services.

Conclusion

The certificate management landscape has been extractive for too long. Teams paying six figures for automation that should be infrastructure primitives. Engineers stitching together fragile shell scripts because "enterprise" meant "enterprise budget." Security teams accepting key escrow as inevitable because the alternative was manual chaos.

certctl says no more. It delivers the full lifecycle — issue, renew, deploy, revoke, alert, audit, govern — with cryptographic security that doesn't trust the control plane, identity integration that doesn't require professional services, and AI accessibility that doesn't compromise attack surface. All self-hosted. All source-available. All free.

The 47-day future is coming whether you're ready or not. The only question is whether you'll face it with a $100K invoice and a 6-month deployment timeline, or with docker compose up and a 30-second demo that proves the impossible is merely unimplemented elsewhere.

Star certctl on GitHub to help others discover it. Open an issue with every IdP quirk, connector edge, and documentation gap you find — that's how the platform earns its production label. The faster the feedback loop, the faster everyone benefits from infrastructure that actually serves operators instead of extracting from them.

Your certificates are expiring. Your automation shouldn't be a line item.