cert-manager in 2026: an architecture note on issuers, orders, and renewal boundaries

A real server-room photograph fits this article because cert-manager only becomes important once certificates stop being abstract padlock icons and start behaving like live infrastructure state inside a cluster control plane.[9]

Most teams first meet cert-manager through a narrow symptom: an Ingress needs TLS, a Gateway needs a certificate, or an internal service mesh wants a more disciplined issuer. That entry point is useful, but it hides the project's actual shape. cert-manager is not mainly an ACME convenience wrapper. It is a Kubernetes certificate control plane that turns desired-state objects into issuance, approval, validation, renewal, and secret-update workflows.[1][2][3]

As of 2026-03-30 UTC, cert-manager/cert-manager reports 13,725 stars, 2,352 forks, 229 open issues, and latest push activity at 2026-03-29T20:47:38Z. The latest GitHub release is v1.20.1, published on 2026-03-27T19:13:14Z.[7][8] That matters because the project is now mature enough that the useful question is not "can it mint a certificate?" The useful question is "where does its reconciliation model begin, and where does it deliberately stop?"

Image context: the cover uses a documentary server-room photograph rather than a lock icon or diagram because cert-manager's real job lives in operations. It manages certificate state for systems that already have namespaces, controllers, queues, and failure domains.[9]

The contract starts with desired state, not with ACME

The Certificate resource is the real center of gravity.[1] It defines the target Secret, the requested subject and SAN shape, the issuer reference, renewal timing, and key-rotation behavior.[1] That architecture choice is more important than the usual "Let's Encrypt for Kubernetes" shorthand because it keeps the system anchored in cluster intent rather than in one external CA workflow.

Once you read cert-manager from the Certificate outward, the design gets clearer:

the application-facing contract is "keep this certificate material current in this Secret"
the issuer-facing contract is "turn this CSR-shaped request into a signed result, or reject it"
the operator-facing contract is "make renewal and key rotation predictable instead of ticket-driven"[1][3]

This is why cert-manager can support more than one issuer family and more than one output shape. The certificate docs describe target-secret behavior, renewal triggers, rotationPolicy, and additional output formats such as CombinedPEM and DER.[1] That is not decorative feature growth. It is evidence that the project sees certificate issuance as an artifact-management problem inside Kubernetes, not only as an HTTP-01 automation script.

Why the separate binaries matter

cert-manager's architecture is easier to reason about when you stop imagining one monolith. The project ships distinct controller, webhook, and cainjector components, each with its own runtime surface and operational flags.[4][5] The older concept docs make the split explicit: the webhook handles admission-time validation, mutation, and conversion for cert-manager API types, while cainjector copies CA bundle data into resources such as webhook configurations and API services that need trust roots kept up to date.[4][5]

That separation is not an implementation detail. It is the reason certain failures feel surprising to first-time operators. If the controller is healthy but the webhook is unavailable, your problem may show up as API rejection long before any issuer interaction occurs.[4] If cainjector falls behind, certificate issuance may still work while trust bundles elsewhere in the cluster lag or drift.[5] cert-manager is therefore not one loop. It is several related loops that meet at different parts of the Kubernetes API surface.

The practical takeaway is simple: "certificate automation" spans more than signing. It also includes API admission and trust-distribution maintenance. Teams that monitor only issuance events usually discover this boundary during an outage rather than during design.

ACME is a second-stage pipeline, not the whole product

ACME support is where cert-manager becomes visible, but the ACME flow is only one branch of the broader architecture. The ACME docs describe how an Order is created to represent a certificate order at the CA, and how that order fans out into one or more Challenge resources that must move through solver-specific validation paths.[2]

Those details matter because they explain where operational pain usually concentrates:

The failure domain is often solver configuration, DNS propagation, or HTTP reachability, not the top-level Certificate manifest.[2]
cert-manager performs self-checks before telling the ACME server to validate, retrying failed self-checks at a fixed 10-second interval.[2]
Challenge scheduling is capped rather than unbounded: the docs note a maximum of 60 simultaneously processed challenges and block certain same-name, same-solver combinations from running at once.[2]

That is a real control plane, not a thin shell script. It means cert-manager is already doing queue discipline and state-machine coordination inside the cluster before the external CA even makes its final decision.

This is also the point where the product's boundary becomes visible. cert-manager can reconcile Order and Challenge state, but it cannot make an external DNS provider converge faster, and it cannot make an application's traffic path expose the right HTTP-01 endpoint if your ingress or gateway routing is wrong. The automation ends where your surrounding infrastructure contract starts.

Approval and renewal are the real production boundary

The approval docs are the clearest evidence that cert-manager is intentionally opinionated about development convenience and much less naive about production.[3] In a default installation, built-in issuers are auto-approved to simplify first-time use. The same page says this is not the recommended posture for production and points operators toward stricter approval policy so you can control who may request which certificates.[3]

That distinction is central. In a toy cluster, the question is "can this namespace obtain a certificate?" In a real platform, the question becomes sharper:

who is allowed to request which SANs or usages
when a request should be denied before it reaches the issuer
whether renewal timing and key rotation line up with application reload behavior
whether your PKI policy lives in cert-manager objects, in the issuer, or in both[1][3]

The docs also make clear that the issuer keeps autonomy after it receives the CSR. An issuer may reject the request, alter the final certificate properties, or apply its own policy logic.[3] That means cert-manager is not your entire trust policy. It is the orchestration layer between Kubernetes intent and issuer judgment.

Recent release work shows where the hard problems still are

The 1.20 release notes are valuable because they show where cert-manager engineering time still goes.[6] The visible fixes are not "how do we create a certificate for the first time?" They are edge-case correctness issues around renewal triggers, ACME DNS-01 cleanup, challenge diagnostics, public-key mismatch loops, and a moderate controller denial-of-service condition tied to cached DNS responses.[6]

That pattern is revealing. Mature infrastructure projects spend less time proving the happy path and more time hardening the state machine around retries, cleanup, drift, and invalid external input. cert-manager fits that pattern now.

A few examples from the current 1.20 line make the point concrete:

changes to Duration and RenewBefore annotations on ingress and Gateway API resources now trigger the expected certificate updates[6]
ACME solver behavior keeps getting tightened, including cleanup and DNS-01 retry correctness[6]
the issuing controller now guards against an infinite re-issuance loop when an issuer returns a certificate whose public key does not match the CSR[6]

In other words, the project's present complexity is not beginner setup. It is long-running reconciliation correctness under imperfect inputs.

Best fit and mismatch boundary

cert-manager is a strong fit when you already accept the Kubernetes model of control planes, CRDs, and reconciliation, and you want certificate lifecycle to obey that same model.[1][2][3] It is especially useful when certificates are not isolated edge assets but recurring platform state: ingress TLS, gateway listeners, internal service identities, and namespaced workloads that need automatic renewal without manual CSR handling.

It is a weaker fit when the real problem sits outside Kubernetes custody. If your difficult work is organization-wide trust policy, secret distribution to non-cluster systems, application hot-reload behavior after Secret updates, or DNS and network ownership outside the cluster team, cert-manager will only solve one layer of the stack. That is not a flaw. It is the correct boundary.

The clean way to evaluate the project is therefore not "does it automate TLS?" The cleaner test is "do we want certificate lifecycle to behave like other Kubernetes state machines, and are we willing to own the infrastructure outside the point where cert-manager intentionally stops?"

cronfeed.work