SelfSigned
⚠️ SelfSigned issuers are generally useful for bootstrapping a PKI locally, which is a complex topic for advanced users. To be used safely in production, running a PKI introduces 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.
The SelfSigned issuer doesn't represent a certificate authority as such, but instead denotes that certificates will "sign themselves" using a given private key. In other words, the private key of the certificate will be used to sign the certificate itself.
This Issuer type is useful for bootstrapping a root certificate for a custom PKI (Public Key Infrastructure), or for otherwise creating simple ad-hoc certificates for a quick test.
There are important caveats - including security issues - to consider with SelfSigned issuers; in general you'd likely want to use a CA issuer rather than a SelfSigned issuer. That said, SelfSigned issuers are really useful for initially bootstrapping a CA issuer.
Note: a
CertificateRequestthat references a self-signed certificate must also contain thecert-manager.io/private-key-secret-nameannotation since the private key corresponding to theCertificateRequestis required to sign the certificate. This annotation is added automatically by theCertificatecontroller.
Deployment
Since the SelfSigned issuer has no dependency on any other resource, it is the simplest to configure. Only the SelfSigned stanza is required to be present in the issuer spec, with no other configuration required:
apiVersion: cert-manager.io/v1kind: Issuermetadata:name: selfsigned-issuernamespace: sandboxspec:selfSigned: {}
apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: selfsigned-cluster-issuerspec:selfSigned: {}
Once deployed, you should be able to see immediately that the issuer is ready for signing:
$ kubectl get issuers -n sandbox -o wide selfsigned-issuerNAME READY STATUS AGEselfsigned-issuer True 2m$ kubectl get clusterissuers -o wide selfsigned-cluster-issuerNAME READY STATUS AGEselfsigned-cluster-issuer True 3m
Bootstrapping CA Issuers
One of the ideal use cases for SelfSigned issuers is to bootstrap a custom root certificate for a private PKI, including with the cert-manager CA issuer.
The YAML below will create a SelfSigned issuer, issue a root certificate and use that root as a CA issuer:
apiVersion: v1kind: Namespacemetadata:name: sandbox---apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: selfsigned-issuerspec:selfSigned: {}---apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: my-selfsigned-canamespace: sandboxspec:isCA: truecommonName: my-selfsigned-casecretName: root-secretprivateKey:algorithm: ECDSAsize: 256issuerRef:name: selfsigned-issuerkind: ClusterIssuergroup: cert-manager.io---apiVersion: cert-manager.io/v1kind: Issuermetadata:name: my-ca-issuernamespace: sandboxspec:ca:secretName: root-secret
Alternatively, if you are looking to use ClusterIssuer for signing Certificates anywhere in your cluster with the SelfSigned Certificate CA, use the YAML below (slight modification):
# `sandbox` namespace is no longer needed.apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: selfsigned-issuerspec:selfSigned: {}---apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: my-selfsigned-ca# Create CA root secret in `cert-manager` namespace instead of `sandbox` namespace.namespace: cert-managerspec:isCA: truecommonName: my-selfsigned-casecretName: root-secretprivateKey:algorithm: ECDSAsize: 256issuerRef:name: selfsigned-issuerkind: ClusterIssuergroup: cert-manager.io---apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: my-ca-issuerspec:ca:# `ClusterIssuer` resource is not namespaced, so `secretName` is assumed to reference secret in `cert-manager` namespace.secretName: root-secret
The "selfsigned-issuer" ClusterIssuer is used to issue the Root CA Certificate. Then, "my-ca-issuer" ClusterIssuer is used to issue but also sign certificates using the newly created Root CA Certificate, which is what you will use for future certificates cluster-wide.
CRL Distribution Points
You may also optionally specify CRL Distribution Points as an array of strings, each of which identifies the location of a CRL in which the revocation status of issued certificates can be checked:
...spec:selfSigned:crlDistributionPoints:- "http://example.com"
Caveats
Trust
Clients consuming SelfSigned certificates have no way to trust them without already having the certificates beforehand, which can be hard to manage when the client is in a different namespace to the server.
This limitation can be tackled by using trust-manager to distribute ca.crt to other namespaces.
There is no secure alternative to solving the problem of distributing trust stores; it's possible to "TOFU" (trust-on-first-use) a certificate, but that approach is vulnerable to man-in-the-middle attacks.
Certificate Validity
One side-effect of a certificate being self-signed is that its Subject DN and its Issuer DN are identical. The X.509 RFC 5280, section 4.1.2.4 requires that:
The issuer field MUST contain a non-empty distinguished name (DN).
However, self-signed certs don't have a subject DN set by default. Unless you manually set a certificate's Subject DN, the Issuer DN will be empty and the certificate will technically be invalid.
Validation of this specific area of the spec is patchy and varies between TLS libraries, but there's always the risk that a library will improve its validation - entirely within spec - in the future and break your app if you're using a certificate with an empty Issuer DN.
To avoid this, be sure to set a Subject for SelfSigned certs. This can be done by setting the spec.subject on a cert-manager Certificate object which will be issued by a SelfSigned issuer.
Starting in version 1.3, cert-manager will emit a Kubernetes warning event of type BadConfig if it detects that a certificate is being created by a SelfSigned issuer which has an empty Issuer DN.