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

<Steps>

<Step>Install the chart with its CRDs</Step>

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

```console
$ 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](/docs/hetzner/apalla/network/dns-certs/certificate-rotation-and-renewal#alert-before-expiry).

<Step>Verify the webhook is healthy</Step>

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:

```console
$ 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.

</Steps>

## 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](/docs/hetzner/apalla/network/dns-certs/lets-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](/docs/hetzner/apalla/network/dns-certs/lets-encrypt-clusterissuer).

<Callout type="tip" title="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).
</Callout>

> [!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

- [Set up a Let's Encrypt ClusterIssuer](/docs/hetzner/apalla/network/dns-certs/lets-encrypt-clusterissuer)
- [Rotate and renew certificates](/docs/hetzner/apalla/network/dns-certs/certificate-rotation-and-renewal)
- [Security on Syself Autopilot](/docs/hetzner/apalla/concepts/ownership/security-model)