Key Concepts: Cert-manager, Issuers, and Secrets

Issuers play the part of certificate authorities (CAs) in the local environment and issue the certificates. Issuers reside in the API Connect namespace. There are two types of Issuers:

• Self-Signed - This issuer provides the self-signed certificates, for example a root CA.
• CA - This issuer can be either the root certificate authority or an intermediate certificate authority.

Here is an example of the issuers that can be found on the management subsystem:

kubectl get issuers -n <management namespace>
NAME                 READY   AGE
abc-management-ca    True    96d
selfsigning-issuer   True    96d

• selfsigning-issuer This is a SelfSigned Issuer that provides the root certificate for all default certificates that are used in API Connect.
• abc-management-ca This is a CA Issuer that signs all the end-entity certificates that are used for communication between the management subsystem pods. It is in effect an intermediate CA between the root (selfsigning-issuer) and the end-entity certificates.

A certificate is a Kubernetes resource that contains a pointer to a Kubernetes secret. The Kubernetes secret contains the actual TLS certificate. Certificate objects contain other information such as the issuer, expiry date, and status. Run kubectl get certificate to see the certificates on an API Connect subsystem:

kubectl get certificate -n <management namespace>
NAME                                      READY   SECRET                                    AGE
abc-management-ca                         True    abc-management-ca                         96d
abc-management-client                     True    abc-management-client                     96d
abc-management-natscluster-mgmt           True    abc-management-natscluster-mgmt           96d
abc-management-server                     True    abc-management-server                     96d
...

The first certificate in the list abc-management-ca is the intermediate CA certificate that is used for signing the other certificates that are shown in the output. If you describe this certificate you can see that the selfsigning-issuer is its issuer:

kubectl describe certificate abc-management-ca -n <management namespace>
...
Spec:
  ...
  Issuer Ref:
    Kind:  Issuer
    Name:  selfsigning-issuer

Describing the other management subsystem certificates, observe that the abc-management-ca certificate is the issuer:

kubectl describe certificates abc-management-client -n <management namespace>
...
Spec:
  ...
  Issuer Ref:
    Kind:  Issuer
    Name:  abc-management-ca

Key points:

• The certificates with '-ca' on the end are all CA Certificates, and they sign all the other subsystem certificates whose names do not end with '-ca'.
• The CA certificates are also known as Issuer certificates.
• Certificates that CA certificates sign are known as end-entity certificates.
• When a CA certificate is updated, all end-entity certificates that it signs must also be updated.

Secrets are the Kubernetes resource for storing credentials. In API Connect, secrets are where the TLS certificates are stored. Every Kubernetes certificate object has a corresponding secret of the same name. The Kubernetes certificate contains a property that refers to its corresponding secret:

kubectl describe certificates abc-management-client -n <management namespace>
...
Spec:
  ...
  Secret Name:        abc-management-client

The default output of kubectl get certificate includes a column that is labeled SECRET, which shows the secret name.

kubectl get certificate -n <management namespace>
NAME                                      READY   SECRET                                    AGE
abc-management-ca                         True    abc-management-ca                         96d
abc-management-client                     True    abc-management-client                     96d
abc-management-natscluster-mgmt           True    abc-management-natscluster-mgmt           96d
abc-management-server                     True    abc-management-server                     96d
...

The kubectl describe output of a secret shows that it contains the TLS certificates:

kubectl describe secret abc-management-client -n <management namespace>
...
Name:         abc-management-client
Namespace:    default
Labels:       app.kubernetes.io/instance=abc-management
              app.kubernetes.io/managed-by=ibm-apiconnect
              app.kubernetes.io/name=abc-management-client
Annotations:  cert-manager.io/alt-names: 
              cert-manager.io/certificate-name: abc-management-client
              cert-manager.io/common-name: abc-management-client
              cert-manager.io/ip-sans: 
              cert-manager.io/issuer-group: 
              cert-manager.io/issuer-kind: Issuer
              cert-manager.io/issuer-name: abc-management-ca
              cert-manager.io/uri-sans: 

Type:  kubernetes.io/tls

Data
====
ca.crt:   1107 bytes
tls.crt:  1139 bytes
tls.key:  1675 bytes

The full TLS certificate strings can be seen with:

kubectl get -o yaml secret <secret name> -n <namespace>