Generating custom certificates manually

Generate custom certificates for API Connect without using cert-manager.

About this task

Note: If you want to customize only your user-facing endpoint certificates, then you do not need to configure them at installation. Install API Connect normally and then update the certificates following the steps in Customizing user-facing certificates.

If you choose to create your certificates manually, then you lose some of the management features of cert-manager. For example, you must manually update your certificates before they expire.

Requirements for manually created certificates:

Extended Key Usage (EKU) must be either serverAuth or clientAuth depending upon the type of certificate. Certificates of the type Server must have an Extended Key Usage with serverAuth purpose. Certificates of the type Client must have an Extended Key Usage with clientAuth purpose.
Subject Alternative Name (SAN) for the required hosts.
If a certificate is signed by an internal or custom CA, include the full chain in the end certificate. If you omit the full chain, then a user who uses OpenSSL to access the endpoint gets the following error: error:num=20:unable to get local issuer certificate
The following example shows the full chain for an end certificate (signed by a custom CA):
```
-------BEGIN CERTIFICATE -----
Cert contents for end-cert
--------END CERTIFICATE ----------
-------BEGIN CERTIFICATE -----
Cert contents for Intermediate-CA
--------END CERTIFICATE ----------
-------BEGIN CERTIFICATE -----
Cert contents for Root CA
--------END CERTIFICATE ----------
```

Procedure

Generate your custom certificates with the appropriate EKU and SAN. You must have the private key, public certificate, and CA certificates in non-password-protected PEM format. Following is an example for how to generate a certificate with an EKU serverAuth and SAN using OpenSSL:
```
openssl x509 -req -days 360 -in platform-api-example.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -out platform-api-cert -sha256  
-extfile <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:fqdn.myserver.com\nextendedKeyUsage=serverAuth")) 
-extensions SAN
```
where
- DNS:fqdn.myserver.com is the fully qualified domain name of the endpoint that the certificate applies to.
- platform-api-example.csr is the file name for the certificate signing request.
The following is an example for how to generate a certificate (portal-client) with an EKU clientAuth and SAN using OpenSSL:
```
openssl x509 -req -days 360 -in portal-client-example.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -out portal-client-cert  
-sha256 -extfile <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nkeyUsage=critical, digitalSignature,keyEncipherment\nextendedKeyUsage = clientAuth\nbasicConstraints=critical, 
CA:FALSE\nsubjectKeyIdentifier=hash\n")) -extensions SAN
```
Note:
When you prepare your custom certificates, certain pairs of certificates must be signed by the same certificate authority, as noted in the description of each certificate: API Connect TLS certificates.

If you're installing a two data center disaster recovery configuration, and are using custom certificates, then the subject names of any client certificates must be the same in both data centers, as noted in the description of each certificate: API Connect TLS certificates. For example, the subject names in both data centers might both be CN=portal-admin-client, or they might both be CN=ptl-adm-client, O=cert-manager, but they must be identical.
Create a Kubernetes secret for each custom certificate.
Create Kubernetes secrets for each of your custom certificates. The secrets must be of type kubernetes.io/tls and must contain the following data items: ca.crt, tls.crt, and tls.key.
```
kubectl create secret generic my-tls-secret --from-file=tls.crt=<path_to_cert_file> --from-file=tls.key=<path_to_key_file> --from-file=ca.crt=<path_to_cacert_file>
```
When you create each secret, it's helpful to reference its purpose or its corresponding certificate in the secret name, to ensure that you specify the correct secret for each custom certificate.

What to do next

Configure your subsystem CR YAML files to use your custom certificates: Deploying API Connect subsystems with custom certificates.