Certificate reference VMware

Details of all API Connect TLS certificates on VMware.

The apicup certs list command returns all the API Connect TLS certificates that can be configured with the apicup command.

Note: The apicup certs list command also returns credentials and encryption secrets that are used by API Connect. For information about these secrets and credentials, see Credentials and encryption secrets reference.

Add the flag --endpoints to see only user-facing endpoint certificates. Add the flag --creds to see only credentials and encryption secrets.

Common certificates

Common certificates exist in all subsystems of an API Connect deployment, and must be identical in each subsystem to enable them to communicate with each other.

Because you deploy your API Connect subsystems from a single project directory, these certificates are automatically set to be the same on all subsystems.

Do not customize any of the common certificates.

Table 1. Common certificates
Certificate name	Description
`root-ca`	CA certificate that is the root of the certificate chain for all other API Connect certificates. Do not update this certificate.
`ingress-ca`	Intermediate CA certificate used to generate all API Connect ingress certificates. Do not customize this certificate. If the certificate expires (duration is 20 years), see: Renewing ingress-ca. If you have multiple data centers that are managed from different project directories, you can synchronize this certificate, see: Synchronizing the ingress-ca certificate.
`appliance-client`	A client certificate that is used by the apicup command to communicate with the API Connect subsystem appliances. Requires EKU `clientAuth`. Do not update this certificate.
`k8s-ca`	CA certificate that forms the root of the certificate chain for the Kubernetes cluster components that run in the API Connect subsystem appliance. Do not update this certificate.

Management certificates

The following table lists the certificates that exist on the management subsystem, in addition to the common certificates.

Table 2. Management subsystem certificates
Certificate name	Description
`portal-client`	The `portal-client` certificate is an inter-subsystem ingress certificate that is presented to the developer portal subsystem during portal service registration. For successful portal registration the `portal-client` certificate must meet these requirements: Specify EKU `clientAuth`. Signed by the same CA (`ingress-ca`) as the `portal-admin-ingress` certificate that secures the admin endpoint on the developer portal. The subject name must match the `adminClientSubjectDN` in the portal subsystem. If you have a multiple data center deployment, both data centers must use an identical subject name. This certificate is loaded by the management subsystem into the `Portal Director TLS client profile` that you can see in the Cloud Manager UI (see TLS profiles). If you want the management subsystem to present a different client certificate to the portal, then create a new profile and specify it when you register the portal service. Do not update this certificate.
`analytics-client-client`	A legacy certificate, it is not used from v10.0.5 onwards.
`analytics-ingestion-client`	The `analytics-ingestion-client` certificate is an inter-subsystem ingress certificate that is presented to the analytics subsystem during analytics service registration. For successful analytics registration the `analytics-ingestion-client` certificate must meet these requirements: Specify EKU `clientAuth`. Signed by the same CA (`ingress-ca`) as the `analytics-ingestion-ingress` certificate that secures the ingestion endpoint on the analytics subsystem. The subject name must match the `clientSubjectDN` in the analytics subsystem. `analytics-ingestion-client` is also used by the gateway subsystem to authenticate with the analytics ingestion endpoint, for the transmission of API event data. This certificate is loaded by the management subsystem into the `Analytics ingestion TLS client profile` that you can see in the Cloud Manager UI (see TLS profiles). If you want the management subsystem to present a different client certificate to the analytics subsystem, then create a new profile and specify it when you register the analytics service. For multiple data center deployments, both data centers must have an identical subject name. Do not update this certificate.
`platform-api`	The `platform-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at cloud scope. The endpoint in the management subsystem configuration uses the same name: `platform-api` The hostnames for which the certificate is valid must include the `platform-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`consumer-api`	The `consumer-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at organization scope. The endpoint in the management subsystem configuration uses the same name: `consumer-api` The hostnames for which the certificate is valid must include the `consumer-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`api-manager-ui`	The `api-manager-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Manager UI. The endpoint in the management subsystem configuration uses the same name: `api-manager-ui`. The hostnames for which the certificate is valid must include the `api-manager-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`cloud-admin-ui`	The `cloud-admin-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the Cloud Manager UI. The endpoint in the management subsystem configuration uses the same name: `cloud-admin-ui`. The hostnames for which the certificate is valid must include the `cloud-admin-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`hub`	Used by the Automated API behavior testing application. User-facing ingress certificate for the `hub-endpoint`.
`management-replication-client`	Used in 2DCDR deployments only. The `management-replication-client` certificate is an inter-subsystem ingress client certificate that is used when connecting to the `management-replication` endpoint in the other data center. Requires EKU `clientAuth`.
`management-replication-ingress`	Used in 2DCDR deployments only. The `management-replication-ingress` certificate is an inter-subsystem ingress server certificate that is used to secure the `management-replication` endpoint. `management-replication-ingress` must be valid for the endpoint defined by `apicup subsys set <subsystem> management-replication=<endpoint>` Requires EKU `serverAuth`.

Portal subsystem certificates

The following table lists the certificates that exist on the management subsystem, in addition to the common certificates.

Table 3. Portal subsystem certificates
Certificate name	Description
`mgmt-consumer-api`	The `mgmt-consumer-api` certificate is an inter-subsystem ingress certificate that secures the consumer API endpoint on the management subsystem. The portal has a copy of this certificate so it can verify that it is communicating with the management subsystem. This certificate must be identical to the `consumer-api` certificate in the management subsystem. Do not update this certificate.
`mgmt-platform-api`	The `mgmt-platform-api` certificate is an inter-subsystem ingress certificate that secures the platform API endpoint on the management subsystem. The portal has a copy of this certificate so it can verify that it is communicating with the management subsystem. This certificate must be identical to the `platform-api` certificate in the management subsystem. Do not update this certificate.
`portal-admin-ingress`	The `portal-admin-ingress` certificate is an inter-subsystem ingress certificate that is used to secure the portal administration endpoint. The management subsystem communicates with this endpoint to register the portal and to send portal configuration updates. Do not update this certificate.
`portal-replication-client`	Used in 2DCDR deployments only. The `portal-replication-client` certificate is an inter-subsystem ingress client certificate that is used when connecting to the `portal-replication` endpoint in the other data center. Requires EKU `clientAuth`.
`portal-replication-ingress`	Used in 2DCDR deployments only. The `portal-replication-ingress` certificate is an inter-subsystem ingress server certificate that is used to secure the `portal-replication` endpoint. `portal-replication-ingress` must be valid for the endpoint defined by `apicup subsys set <subsystem> portal-replication=<endpoint>` Requires EKU `serverAuth`.
`portal-www-ingress`	The `portal-www-ingress` certificate is a user-facing ingress certificate that is returned to users when they attempt to access developer portal sites. The endpoint is called `portal-www` in the portal subsystem configuration.

Analytics subsystem certificates

The following table lists the certificates that exist on the management subsystem, in addition to the common certificates.

Table 4. Analytics subsystem certificates
Certificate name	Description
`analytics-ca`	Internal certificate used for communication between analytics subsystem components. Do not update this certificate.
`analytics-ingestion-ingress`	The `analytics-ingestion-ingress` certificate is an inter-subsystem ingress certificate that is used to secure the analytics ingestion endpoint, which is used for the following: Receiving API event data from associated gateways. Configuration and analytics queries from the management subsystem. Do not update this certificate.
`service-client`	Internal certificate used for communication between analytics subsystem components. Do not update this certificate.
`service-server`	Internal certificate used for communication between analytics subsystem components. Do not update this certificate.

Ingress certificates

The following table lists all the certificates across all subsystems that are signed by the ingress-ca. If you renew your ingress-ca certificate, then you must also renew all the ingress end-entity certificates that are listed in this table. For steps on renewing the ingress-ca, see Renewing ingress-ca.

Table 5. Certificates signed by `ingress-ca`
Certificate name	Description
`portal-client`	The `portal-client` certificate is an inter-subsystem ingress certificate that is presented to the developer portal subsystem during portal service registration. For successful portal registration the `portal-client` certificate must meet these requirements: Specify EKU `clientAuth`. Signed by the same CA (`ingress-ca`) as the `portal-admin-ingress` certificate that secures the admin endpoint on the developer portal. The subject name must match the `adminClientSubjectDN` in the portal subsystem. If you have a multiple data center deployment, both data centers must use an identical subject name. This certificate is loaded by the management subsystem into the `Portal Director TLS client profile` that you can see in the Cloud Manager UI (see TLS profiles). If you want the management subsystem to present a different client certificate to the portal, then create a new profile and specify it when you register the portal service. Do not update this certificate.
`analytics-client-client`	A legacy certificate, it is not used from v10.0.5 onwards.
`analytics-ingestion-client`	The `analytics-ingestion-client` certificate is an inter-subsystem ingress certificate that is presented to the analytics subsystem during analytics service registration. For successful analytics registration the `analytics-ingestion-client` certificate must meet these requirements: Specify EKU `clientAuth`. Signed by the same CA (`ingress-ca`) as the `analytics-ingestion-ingress` certificate that secures the ingestion endpoint on the analytics subsystem. The subject name must match the `clientSubjectDN` in the analytics subsystem. `analytics-ingestion-client` is also used by the gateway subsystem to authenticate with the analytics ingestion endpoint, for the transmission of API event data. This certificate is loaded by the management subsystem into the `Analytics ingestion TLS client profile` that you can see in the Cloud Manager UI (see TLS profiles). If you want the management subsystem to present a different client certificate to the analytics subsystem, then create a new profile and specify it when you register the analytics service. For multiple data center deployments, both data centers must have an identical subject name. Do not update this certificate.
`platform-api`	The `platform-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at cloud scope. The endpoint in the management subsystem configuration uses the same name: `platform-api` The hostnames for which the certificate is valid must include the `platform-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`consumer-api`	The `consumer-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at organization scope. The endpoint in the management subsystem configuration uses the same name: `consumer-api` The hostnames for which the certificate is valid must include the `consumer-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`api-manager-ui`	The `api-manager-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Manager UI. The endpoint in the management subsystem configuration uses the same name: `api-manager-ui`. The hostnames for which the certificate is valid must include the `api-manager-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`cloud-admin-ui`	The `cloud-admin-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the Cloud Manager UI. The endpoint in the management subsystem configuration uses the same name: `cloud-admin-ui`. The hostnames for which the certificate is valid must include the `cloud-admin-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`hub`	Used by the Automated API behavior testing application. User-facing ingress certificate for the `hub-endpoint`.
`portal-admin-ingress`	The `portal-admin-ingress` certificate is an inter-subsystem ingress certificate that is used to secure the portal administration endpoint. The management subsystem communicates with this endpoint to register the portal and to send portal configuration updates. Do not update this certificate.
`portal-www-ingress`	The `portal-www-ingress` certificate is a user-facing ingress certificate that is returned to users when they attempt to access developer portal sites. The endpoint is called `portal-www` in the portal subsystem configuration.
`analytics-ingestion-ingress`	The `analytics-ingestion-ingress` certificate is an inter-subsystem ingress certificate that is used to secure the analytics ingestion endpoint, which is used for the following: Receiving API event data from associated gateways. Configuration and analytics queries from the management subsystem. Do not update this certificate.
`management-replication-client`	Used in 2DCDR deployments only. The `management-replication-client` certificate is an inter-subsystem ingress client certificate that is used when connecting to the `management-replication` endpoint in the other data center. Requires EKU `clientAuth`.
`management-replication-ingress`	Used in 2DCDR deployments only. The `management-replication-ingress` certificate is an inter-subsystem ingress server certificate that is used to secure the `management-replication` endpoint. `management-replication-ingress` must be valid for the endpoint defined by `apicup subsys set <subsystem> management-replication=<endpoint>` Requires EKU `serverAuth`.
`mgmt-consumer-api`	The `mgmt-consumer-api` certificate is an inter-subsystem ingress certificate that secures the consumer API endpoint on the management subsystem. The portal has a copy of this certificate so it can verify that it is communicating with the management subsystem. This certificate must be identical to the `consumer-api` certificate in the management subsystem. Do not update this certificate.
`mgmt-platform-api`	The `mgmt-platform-api` certificate is an inter-subsystem ingress certificate that secures the platform API endpoint on the management subsystem. The portal has a copy of this certificate so it can verify that it is communicating with the management subsystem. This certificate must be identical to the `platform-api` certificate in the management subsystem. Do not update this certificate.
`portal-replication-client`	Used in 2DCDR deployments only. The `portal-replication-client` certificate is an inter-subsystem ingress client certificate that is used when connecting to the `portal-replication` endpoint in the other data center. Requires EKU `clientAuth`.
`portal-replication-ingress`	Used in 2DCDR deployments only. The `portal-replication-ingress` certificate is an inter-subsystem ingress server certificate that is used to secure the `portal-replication` endpoint. `portal-replication-ingress` must be valid for the endpoint defined by `apicup subsys set <subsystem> portal-replication=<endpoint>` Requires EKU `serverAuth`.

User-facing certificates

The following table lists all the certificates that are used for user-facing endpoints.

Table 6. User-facing endpoint certificates.
Certificate name	Description
`portal-www-ingress`	The `portal-www-ingress` certificate is a user-facing ingress certificate that is returned to users when they attempt to access developer portal sites. The endpoint is called `portal-www` in the portal subsystem configuration.
`api-manager-ui`	The `api-manager-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Manager UI. The endpoint in the management subsystem configuration uses the same name: `api-manager-ui`. The hostnames for which the certificate is valid must include the `api-manager-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`cloud-admin-ui`	The `cloud-admin-ui` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the Cloud Manager UI. The endpoint in the management subsystem configuration uses the same name: `cloud-admin-ui`. The hostnames for which the certificate is valid must include the `cloud-admin-ui` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`consumer-api`	The `consumer-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at organization scope. The endpoint in the management subsystem configuration uses the same name: `consumer-api` The hostnames for which the certificate is valid must include the `consumer-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`platform-api`	The `platform-api` certificate is a user-facing ingress certificate that is returned to users when they attempt to access the API Connect REST API at cloud scope. The endpoint in the management subsystem configuration uses the same name: `platform-api` The hostnames for which the certificate is valid must include the `platform-api` endpoint. A wildcard certificate can be used as the first element in a hostname, for example, if the endpoint is: `store.acme.com`, the certificate can be one that is valid for hostnames that match `*.acme.com`. Requires EKU `serverAuth`.
`hub`	Used by the Automated API behavior testing application. User-facing ingress certificate for the `hub-endpoint`.