↓ Skip to main content
Le Site de François
  1. Index/

cert-manager

Kubernetes Security Tls Pki Certificates Cncf Automation

cert-manager is a CNCF graduated project that brings PKI lifecycle management into Kubernetes as a first-class controller, eliminating the manual processes — CSR generation, CA submission, secret rotation, renewal tracking — that cause certificate-related outages in clusters that manage TLS manually. Its premise is that X.509 certificates should be declared as Kubernetes resources with the same GitOps-friendly, reconciliation-driven lifecycle as any other workload configuration: an operator declares the desired certificate, cert-manager continuously ensures that a valid, non-expired certificate matching that declaration exists and is stored in a Kubernetes Secret, and renews it automatically before expiry. The default renewal threshold is two-thirds of the certificate’s validity period, so a certificate with a 90-day lifetime is renewed at 60 days without operator intervention.

cert-manager introduces four core Custom Resource Definitions that together model the complete certificate issuance pipeline. An Issuer (namespace-scoped) or ClusterIssuer (cluster-wide) defines a backend that can sign certificates — its type determines how signing happens. Built-in issuer types include: ACME (implements RFC 8555 to obtain publicly-trusted certificates from Let’s Encrypt or any ACME-compatible CA using HTTP-01 or DNS-01 challenge solvers), CA (signs with a CA key pair stored in a Kubernetes Secret, suitable for internal PKIs), Vault (delegates signing to Vault’s PKI secrets engine, the standard choice for organisations with an existing Vault-based CA hierarchy), and SelfSigned (issues certificates signed by their own private key, used primarily for bootstrapping CA certificates). The external issuer model extends this list via a standardised webhook protocol: Venafi, Google Certificate Authority Service, AWS PCA, step-ca, and many others implement cert-manager-compatible issuers as separate controllers. A Certificate resource is the human-authored declaration of what certificate is needed: the desired DNS names, SPIFFE URIs, IP addresses, key algorithm, key usages, validity duration, and a reference to the Issuer that should sign it. cert-manager’s controller watches Certificate resources, generates a private key (which never leaves the cluster node in CSI-driver deployments, and is stored in a Secret in the standard deployment), creates a CertificateRequest containing the CSR, and submits it to the referenced issuer. The CertificateRequest is the fourth CRD and the internal unit of work: it represents a single signing operation and can be approved automatically by cert-manager’s default approver or held for approval by a policy engine (approver-policy) that enforces constraints on what certificates workloads are allowed to request. Once signed, the certificate and key are stored in the Secret named in the Certificate spec, where they can be mounted by pods, consumed by Ingress controllers, or referenced by other cert-manager-aware components.

Beyond the core Certificate resource, cert-manager ships a family of satellite components for more specialised use cases. The cert-manager CSI driver (csi-driver) mounts certificates directly into pod filesystems as ephemeral volumes, generating a unique private key per pod on the node — the key never enters a Secret or etcd, and the certificate is automatically renewed and remounted before expiry. csi-driver-spiffe extends this to deliver SPIFFE X.509-SVIDs: every pod that mounts the CSI volume receives a certificate with its SPIFFE ID in the SAN, automatically rotated, without any application code changes — a lighter-weight alternative to a full SPIRE deployment for clusters where cert-manager already manages PKI. istio-csr implements the Istio Certificate Signing Request API, allowing Istio to delegate certificate issuance for its mTLS sidecar mesh to cert-manager rather than Istio’s built-in Citadel CA, giving operators a single PKI control plane for both workload certificates and mesh identity. trust-manager handles trust bundle distribution: it watches for CA certificate changes and propagates updated trust bundles into ConfigMaps across namespaces, keeping the trust stores that applications and Ingress controllers use to verify certificates in sync with the PKI that cert-manager manages. In the PQC transition, cert-manager is the natural integration point for deploying ML-DSA certificates at scale: a ClusterIssuer backed by a Vault PKI engine configured with an ML-DSA intermediate CA, combined with cert-manager’s automatic renewal, provides the operational path for rotating an entire cluster’s TLS certificate population to quantum-safe signatures without per-service manual intervention.

Related

CRL (Certificate Revocation List)

Security Pki X509 Certificates Revocation Tls
A Certificate Revocation List (CRL) is a signed data structure, published by a Certificate Authority as part of its PKI operations, that lists the serial numbers of X.509 certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject’s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where OCSP is impractical.

OCSP (Online Certificate Status Protocol)

Security Pki X509 Certificates Revocation Tls
OCSP (Online Certificate Status Protocol), standardised in RFC 6960, is a request-response protocol that allows a verifier to query an OCSP responder — a service operated by the CA or a delegated party — for the current revocation status of a specific X.509 certificate. Where a CRL requires downloading an entire list and searching it locally, an OCSP query asks about exactly one certificate and receives a signed response: good (the certificate is currently valid and not revoked), revoked (revoked, with the revocation time and reason), or unknown (the responder does not know this certificate). The OCSP response is signed by the CA’s OCSP signing key (or a dedicated OCSP responder key with the id-pkix-ocsp-nocheck extension, exempt from its own revocation checking to prevent circularity) and carries a thisUpdate and nextUpdate timestamp defining its freshness window. Verifiers in strict mode reject responses outside the freshness window; in practice, OCSP responses are valid for 24 hours to 7 days depending on the CA’s policy, meaning OCSP shares CRL’s staleness problem, albeit with a smaller window.

PKI (Public Key Infrastructure)

Security Cryptography Certificates Identity Tls Pki
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.