---
title: CA
description: 'cert-manager configuration: CA Issuers'
---

:::warning
⚠️ CA issuers are generally for cert-manager demos or for advanced users with experience
and tooling for running a PKI. To be used safely in production, CA issuers introduce complex
planning requirements around rotation, trust store distribution and disaster recovery.

If you're not planning to run your own PKI, use a different issuer type.

Otherwise, be sure to read the [Important Information](#important-information) below.

:::

The CA issuer represents a Certificate Authority whose certificate and
private key are stored inside the cluster as a Kubernetes `Secret`.

Certificates issued by a CA issuer will not be publicly trusted and so are unlikely to be trusted
by your applications without further configuration.

Consider [trust-manager](../trust/trust-manager/README.md) for distributing your CA certificate safely
across your cluster!

## Deployment

CA Issuers must be configured with a certificate and private key stored in a Kubernetes
secret. You can create this externally if you wish, or you could bootstrap a root certificate
using a [`SelfSigned` issuer](./selfsigned.md#bootstrapping-ca-issuers).

Your certificate's secret should reside in the same namespace as the `Issuer`, or otherwise
in the `Cluster Resource Namespace` in the case of a `ClusterIssuer`.

The `Cluster Resource Namespace` is defaulted as being the `cert-manager` namespace, but
can be configured using the `--cluster-resource-namespace` flag on the cert-manager controller.

Below is an example of a secret resource that will be used for signing. Take
note of the index keys used for each field as these are required in order for
cert-manager to find the certificate and key. Also note that, like all secrets,
data must be base64 encoded. The command `$ cat crt.pem | base64 -w0` should help you
on GNU-based systems (Debian, Ubuntu, etc.) and `$ cat crt.pem | base64 -b0` on BSD-based
systems (most notably macOS).

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: ca-key-pair
  namespace: sandbox
data:
  tls.crt:  
  tls.key:  
```

> Note: If your issuer represents an intermediate, ensure that `tls.crt` contains
> the issuer's full chain in the correct order: `issuer -> intermediate(s) -> root`.
> The root (self-signed) CA certificate is optional, but adding it will ensure that
> the correct CA certificate is stored in the secrets for issued `Certificate`s under
> the `ca.crt` key. If you fail to provide a complete chain, it might not be possible
> for consumers of issued `Certificate`s to verify whether they're trusted.

Next is to deploy the CA issuer which references this `Secret`. This is done by
referencing the secret name under the `ca` stanza in the `Issuer` spec.

```yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: sandbox
spec:
  ca:
    secretName: ca-key-pair
```

Optionally, you can specify [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list) Distribution Points; an array of strings each of which identifies the location of the CRL from which the revocation of this certificate can be checked.

```yaml
...
spec:
  ca:
    secretName: ca-key-pair
    crlDistributionPoints:
    - "http://example.com"
```

Once deployed, you can then check that the issuer has been successfully
configured by checking the ready status of the certificate. Replace `issuers`
here with `clusterissuers` if that is what has been deployed.

```bash
$ kubectl get issuers ca-issuer -n sandbox -o wide
NAME          READY   STATUS                AGE
ca-issuer     True    Signing CA verified   2m
```

Certificates are now ready to be requested by using the CA `Issuer` named
`ca-issuer` within the `sandbox` namespace.

## Important Information

The CA issuer is lightweight and is intended for experienced cluster operators who understand
PKI and the need for planning around certificate rotation.

You should bear the following in mind:

- There's no automatic rotation for the CA certificate in the `Secret` you configured
   - If running a long-lived CA issuer, you need a plan for rotating the CA certificate
   - You should have tracking in place to warn you when the CA cert is nearing expiry
- CA issuers will issue leaf certificates which outlive the CA
   - There is no check performed on the duration of the leaf relative to the duration of the CA
   - You'll need to track the expiry of _all_ certificates in the chain
- Updating the secret used for the CA certificate won't trigger re-issuance of leaf certificates
   - If your CA was near expiry and your leaf certs weren't, you'll need to manually trigger re-issuance of the leaf certs
   - `cmctl renew` may be helpful for this (see the [`cmctl` docs](../reference/cmctl.md#renew))
- CA issuers don't validate that the CA you configure is a "valid" CA
   - At a minimum, CA certs should have the basic constraints extension present with `isCA` set to true
   - The basic constraints extension with `isCA` set to true is required, but other requirements are not checked
   - Most likely, you'll also need to set `certificate sign` on the key usages
   - For generating a cert with cert-manager - which automatically sets the correct usages - see the [bootstrapping example](./selfsigned.md#bootstrapping-ca-issuers)
   - Other constraints - such as name constraints or the CA "max path length" - are not validated at the time of issuance
