cert-manager Is Excellent at Automation.
Governance Is a Different Problem.

May 2026 • 9 min read • Kubernetes

cert-manager is one of the best things to happen to Kubernetes operations in a decade. It eliminated the soul-crushing ritual of manually renewing TLS certificates, integrated cleanly into existing GitOps workflows, and handles ACME renewals so reliably that most teams forget it's running.

That last part is the problem.

When certificate issuance is frictionless, it becomes invisible. And invisible certificate activity is exactly what creates the compliance gaps, shadow certs, and production outages that keep security teams up at night — especially as the CA/Browser Forum drives certificate lifetimes down to 47 days.

The Gap cert-manager Was Never Designed to Fill

cert-manager is an automation engine. It does one thing extraordinarily well: watch for Certificate resources, issue them, and keep them renewed. That is its entire mandate, and it executes it flawlessly.

But automation has no opinions about what it is automating. cert-manager will happily:

Issue a wildcard certificate for *.yourdomain.com without any approval
Renew a certificate for a decommissioned service because no one removed the manifest
Use a CA that doesn't match your security policy for that environment
Produce zero audit trail that an auditor or SIEM can actually consume

None of this is a bug in cert-manager. Governance is intentionally out of scope. The expectation was always that teams would build the policy layer themselves. Most haven't.

The Governance Layer Pattern

The architectural answer is clean: keep cert-manager doing what it does best, and introduce a governance proxy that intercepts all issuance requests before they reach the CA. cert-manager never knows the proxy exists. Every request flows through policy enforcement, approval routing, and audit logging first.

How CertForge Plugs In

CertForge ships a Kubernetes External Issuer — a custom controller that implements the cert-manager Signer interface. From cert-manager's perspective, CertForge is just another Issuer. Your existing Certificate manifests don't change shape; you just point issuerRef at a CertForgeIssuer resource instead of a built-in one.

Behind that interface, CertForge evaluates every signing request against your Domain Trust Profiles — policy definitions that specify which CAs are permitted for a given domain pattern, what approval workflow applies, and what constraints (SANs, validity, key type) are enforced. If the request matches a profile and meets its conditions, it proceeds. If it doesn't match, it is rejected before it ever reaches a CA.

Approval Workflows That Match How Teams Actually Work

Not every certificate carries the same risk. A cert-manager renewal for an internal dev service is operationally routine. A new wildcard for a payment-processing domain is not. A sensible governance model treats them differently — automatically, based on the trust profile you configured.

CertForge supports the full spectrum of approval modes, configured per trust profile:

Zero-touch auto-approval — Renewals and low-risk issuance that fully satisfy policy proceed immediately with no human latency.
Single-approver — The request goes to one designated person or role. Most production domains fall here.
Multi-level sequential — Platform engineering approves first, then Security reviews. Common for customer-facing infrastructure.
Parallel quorum — Two of three named approvers must sign off. Useful for sensitive services where no single person should have unilateral authority.
Break-glass override — A time-limited emergency bypass with mandatory post-review, audit timestamp, and justification requirement. For real incidents, not shortcuts.

Approvers receive instant notifications via Slack, Microsoft Teams, or Webex and can approve or reject directly from the notification — no context switching to a separate tool. The decision, the approver identity, and any comments are recorded permanently.

Discovery: Finding the Certificates You Don't Know About

Governance over new certificate requests is necessary but not sufficient. Most organizations have years of certificates issued before any governance layer existed — by individual developers with their own ACME credentials, by forgotten CI pipelines, by SaaS tools that provision TLS automatically.

CertForge's discovery engine continuously scans your domains and CT logs, fingerprints active certificates, and surfaces everything in a unified inventory. You see who issued each cert, what CA signed it, when it expires, and whether it falls under a known trust profile. Unrecognized certificates trigger an alert. Shadow certificate debt becomes visible and manageable instead of quietly growing.

The Audit Trail Auditors Actually Accept

Every event that flows through CertForge — request received, policy evaluated, approval requested, decision recorded, CA issuance attempted, certificate delivered — produces a structured, immutable audit record. Those records stream in real time to your SIEM in JSON, CEF, or Syslog format. When an auditor asks for the complete issuance history for a domain, you produce it in seconds.

Setup: Minutes, Not Months

Install the CertForge Issuer into your cluster:

helm install certforge-issuer \
  oci://ghcr.io/certforge-llc/charts/certforge-issuer \
  --namespace certforge-system \
  --create-namespace \
  --set certforge.url=https://app.certgovernance.app \
  --set certforge.token=YOUR_API_TOKEN

Then point your existing Certificate resources at the new issuer:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-service-tls
spec:
  secretName: my-service-tls
  dnsNames:
    - my-service.example.com
  issuerRef:
    name: certforge        # was: letsencrypt-prod
    kind: CertForgeIssuer
    group: certforge.io

That's it. cert-manager continues managing the full Kubernetes lifecycle. CertForge handles policy, approvals, and audit on every signing request — with no changes to your broader cluster configuration or deployment workflows.

cert-manager automates the how. CertForge governs the what and the why.

Together they give you the operational efficiency of full automation and the security posture of a mature certificate governance program — without the six-figure CLM platform or the six-month implementation project.

Is This Right for You?

CertForge is the right layer if any of these apply:

You run cert-manager in production and your last "certificate audit" was running kubectl get secrets
Security or compliance teams have asked for issuance reports and you had nothing to give them
You have customer-facing, payment, or health-data domains and no approval gate in front of certificate issuance
Your org is subject to SOC 2, ISO 27001, PCI-DSS, HIPAA, or CMMC and certificate lifecycle is in scope
You are already thinking about what 47-day certificates mean for your on-call rotation in 2029

Self-hosting available for regulated environments. No card required to start.

Add Governance to Your cert-manager Clusters

cert-manager Is Excellent at Automation.Governance Is a Different Problem.