Install cert-manager

Inspect 1.36

cert-manager requests TLS certificates, stores them in Secrets, and renews them before they expire, so your ingress always has a valid certificate without requiring you to track expiry dates. Syself Autopilot does not provide it; you install it yourself as a normal workload.

Install and verify

Install the chart with its CRDs

Install cert-manager and its custom resources into a dedicated namespace:

		$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

The cert-manager webhook sits on the API path for every issuer and Certificate request so it is an important component that needs spreading, so run two of it with --set webhook.replicaCount=2 --set webhook.podDisruptionBudget.enabled=true and admission survives losing a node.

Replicas alone do not prevent outages. Set up alerting for two critical failure conditions:

Controller and webhook availability: Alert if the cert-manager controller or webhook deployments become unready or crash-loop, which halts automated renewals and blocks admission validation for new resources.
Impending certificate expiry: A stalled renewal restarts no pod and fails no deployment, staying invisible until a certificate expires and your ingress serves an invalid chain. Alert on remaining certificate validity (for example, when under 14–21 days remain) as described in Rotate and renew certificates .

Verify the webhook is healthy

cert-manager runs an admission webhook that validates every issuer and Certificate you create, and nothing functions until it is ready. Check that its deployments are available before you create an issuer:

		$ kubectl get pods -n cert-manager
NAME                          READY   STATUS    RESTARTS   AGE
cert-manager-...              1/1     Running   0          2m
cert-manager-cainjector-...   1/1     Running   0          2m
cert-manager-webhook-...      1/1     Running   0          2m

Tip

If a Certificate or Issuer you create fails validation, hangs without status updates, or shows no events, inspect the cert-manager-webhook pod logs and health first.

What certificates can cert-manager issue?

cert-manager manages standard X.509 TLS certificates across several trust models, domains, and application use cases:

Public web certificates: Automated, browser-trusted TLS certificates via Let's Encrypt or ZeroSSL (ACME) for public-facing Ingresses and APIs. Supports single domains, multi-domain SANs, and wildcard certificates (*.example.com validated through DNS-01 challenges).
Internal and private PKI: Certificates signed by an internal root or intermediate CA stored in a Kubernetes Secret, or delegated to HashiCorp Vault or enterprise PKI (such as Venafi or AWS Private CA). Used for cluster-internal microservices, zero-trust architectures, and private endpoints.
Client and mutual TLS (mTLS): Client certificates used for pod-to-pod authentication, database connectivity, or service mesh mutual TLS.
Self-signed and bootstrap certificates: Ephemeral certificates generated directly by the cluster without an external authority, ideal for local development, testing, or bootstrapping an internal root CA.

Choose a certificate source

An issuer tells cert-manager where certificates come from, and the kind you pick decides who trusts the result. Settle that before you decide where the issuer lives.

Issuer type	Issues	Use it for
`acme`	Publicly trusted certificates from Let's Encrypt or another ACME CA	Internet-facing ingress hosts
`ca`	Certificates signed by a CA key pair you hold in a Secret	An internal PKI whose root you distribute to your own clients
`selfSigned`	Certificates signed by their own key	Bootstrapping a `ca` issuer, and mTLS between workloads you control
`vault`	Certificates from a Vault PKI secrets engine	Clusters that already issue from Vault
`venafi`	Certificates through Venafi TPP or Venafi Cloud	Organizations with a central enterprise PKI

External issuers such as AWS Private CA and Google Certificate Authority Service plug in as separate controllers with their own CRDs, and follow the same scoping rules as the built-in kinds.

Most clusters need only acme, which produces the browser-trusted certificate an ingress serves. See set up a Let's Encrypt ClusterIssuer .

Choose between Issuer and ClusterIssuer

cert-manager supports both namespaced and cluster-scoped certificate authorities depending on your isolation requirements:

Issuer (namespaced): Scoped strictly to the namespace where it is defined. Use an Issuer to isolate credentials, internal PKIs, or private CA configurations within a specific tenant or application boundary.
ClusterIssuer (cluster-wide): Accessible from any namespace across the cluster. Use a ClusterIssuer for shared services, such as a cluster-wide Let's Encrypt setup for public HTTP/S Ingresses.

For standard public web applications, you can configure a cluster-wide Let's Encrypt ClusterIssuer so any Ingress can request TLS certificates automatically without duplicating issuer configurations per namespace. See set up a Let's Encrypt ClusterIssuer .

Prefer not to run it yourself?

cert-manager, a `ClusterIssuer`, and DNS wiring are a small but real operational responsibility. Syself can set this up for you and keep it running, from a one-time setup to a fully managed arrangement. Contact [contact@syself.com](mailto:contact@syself.com).

Note

When you upgrade cert-manager, upgrade its CRDs to match the chart version. A chart running against older CRDs is a common cause of certificates that silently stop reconciling.

Where to go next

Automate DNS records with external-dns

Let external-dns publish and update A and AAAA records for your Services and Ingresses automatically at your DNS provider.

Set up a Let's Encrypt ClusterIssuer

Create a Let's Encrypt ClusterIssuer and let cert-manager fetch free certificates for every ingress in the cluster.