Certificate management: Read This First

Requirements and best practices for managing API Connect certificates.

Important: Customization of public certificates and public user-facing certificates is recommended. Customization of internal certificates is strongly discouraged.

For management purposes, API Connect certificates can be grouped by type (default, custom, and common) and by usage (public, public and user-facing, and internal). Understand each type and usage before you change any certificates.

A default certificate is a private certificate that is uniquely generated by the installer for the current project directory, and will pass validation. Default certificates are automatically generated for each subsystem by the apicup subsys install command, unless the certificates were explicitly set by using the apicup certs set command. Note that the default certificates are self-signed, so they might not provide a level of trust suitable for external communication.
For optimal trust levels, we recommend that you explicitly set all public and user-facing certificates by creating custom certificates.
Some certificates are common across subsystems. Subsystems require the common certificates to allow them to register with the management subsystem. When installing any one subsystem, the common certificates are set for that subsystem and for all the other subsystems. If you use custom certificates for the common certificates, the custom certificates must be set prior to setting any other custom certificates.
We do not recommend the explicit setting of internal certificates. The changing of internal certificates creates a risk of incompatibility with other internal certificates.

To review the usage (public, public and user-facing, or internal) of each certificate, see the following Certificate management best practice table.

Table 1. Certificate management best practice
Certificate usage	Certificate name	Best practice management
Public and User-facing	platform-api, api-manager-ui, cloud-admin-ui consumer-api portal-www-ingress hub-endpoint turnstile-endpoint management-replication-ingress portal-replication-ingress	For optimal trust levels, set these explicitly. Recommended to be explicitly set as custom certificates because they are presented to an end user through a browser or Command Line Interface (CLI).
Internal	root-ca, ingress-ca portal-admin-ingress, portal-client analytics-ingestion-ingress, analytics-ingestion-client For VMware appliance deployments only: k8s-ca, appliance-client	Do not change. Accept the default certificates. It is possible to change these certificates (except ingress-ca) but is strongly discouraged because you risk creating incompatibilities that can block internal communications. Each intermediate cert is used to generate other internal certs. If, for example, you change an intermediate cert, the certs generated from it might not work with internal certs generated from other intermediate certs. Note that ingress-ca is auto-generated and cannot be set using the `apicup certs set` command.