cert-manager 1.21.3: what a trust-store update means for your cluster

The cert-manager project released v1.21.3 on October 23, 2026. Among other changes, it updates base images to remove the emSign ECC Root CA - G3 root certificate and uses Go 1.26.10, whose crypto/x509 rejects chains through the compromised intermediates described by the release. The project recommends that all users upgrade.

This is a good moment to map which component trusts which CA. Updating the controller image is not equivalent to updating the trust stores of every application, ingress proxy, browser, or workload in the cluster. Likewise, an affected connection is not established merely because a cluster uses cert-manager: its actual peer chain and the trust configuration of the component making the connection matter.

Three other changes in the same release

The release notes also describe:

1. ARI renewal loop fix. Stale renewal information from the previous certificate could trigger repeated issuance until a CA rate limit was reached. The fix tracks the certificate ID and re-fetches renewal information for a new certificate.
2. Next private-key Secret ownership. The issuance controllers now check that the designated Secret has the expected label and is owned by the Certificate before consuming it. The release describes a scenario requiring permission to write the certificates/status subresource.
3. Proxy values in Helm. Proxy environment values are quoted during rendering, avoiding manifest breakage from values such as a wildcard pattern.

Those are distinct issues; a single “certificate bug” label would hide which evidence an operator needs.

A practical review before upgrading

• Inventory the cert-manager controller version, deployment method and Kubernetes version. Check the project’s supported-release table and vendor guidance where a distribution manages upgrades.
• Identify outbound connections made by cert-manager components, such as configured ACME or Vault endpoints. For each one, determine the chain and actual trust source before drawing conclusions about impact. PKI Channel’s OpenSSL chain guide (Japanese) separates certificates sent by the peer from the independently trusted root, and shows hostname verification. Its OpenSSL result does not establish which trust store cert-manager actually uses.
• Read the release notes and applicable upgrade notes, then render and validate your own configuration in a non-production environment. Pay particular attention to proxy settings and Secret ownership assumptions.
• Exercise a representative issuance and renewal in that environment; verify the Secret and certificate presented by the intended endpoint. A successful controller rollout alone does not prove the application loaded a new certificate. If issuance stops or the endpoint still serves an older certificate, PKI Channel’s renewal runbook (Japanese) traces Certificate and CertificateRequest through the applicable ACME objects, then compares the Secret with the endpoint.
• Track failures, rollback conditions and the owner of each downstream connection. Do not restore a removed trust anchor merely to suppress an error; investigate the affected chain and use the vendor’s current incident guidance.

These are suggested checks, not tests performed for this article. The upstream release notes remain the source for the release-specific changes.

AI assistance was used to draft the text and create the illustrations. The release-specific claims were checked against the upstream release notes; the suggested tests were not performed for this article.