List of internal certificates

A summary of certificates used for communications within subsystems in an API Connect deployment.

Table 1 presents a list of certificates used for microservice-to-microservice communications with the corresponding secret and affected pods. The certificates in Table 1 must be specified using cert-manager. The issuer can be any cert-manager issuer (default is selfsigning-issuer) using the custom-certs-internal.yaml template.

Table 1. Internal certificates, secrets, and affected pods
Issuer / CA Certificate	Certificate	Usage	Secret	Pods¹
`analytics_CR-ca`	`analytics_CR-client`	client	`analytics_CR-client`	`analytics_CR-*`
`analytics_CR-ca`	`analytics_CR-server`	server	`analytics_CR-server`	`analytics_CR-*`
`management_CR-ca`	`apicuser`	client	`management_CR-db-client-apicuser`	`apim` `hub` `lur` `portal_CR-proxy` `taskmanager` `postgres-pgbouncer`
`management_CR-ca`	`management_CR-client`	client	`management_CR-client`	`analytics_CR-proxy` `apim` `apiconnect-operator` `hub` `juhu` `ldap` `lur` `portal_CR-proxy` `stancluster` `taskmanager` `turnstile` `management_CR-sitename-postgres` `management_CR-tunnel` (on active site in 2DC-HA configuration)
`management_CR-ca`	`management_CR-server`	server	`management_CR-server`	`analytics_CR-proxy` `apim` `billing` `client-downloads-server` `hub` `juhu` `ldap` `lur` `portal_CR-proxy` `natscluster` `taskmanager` `turnstile` `ui` `management_CR-remote-sitename-postgres` (on warm-standby site in 2DC-HA config)
`management_CR-ca`	`management_CR-random-postgres`	server	`management_CR-random-postgres`	`apim` `postgres-*` `lur` `portal_CR-proxy` `taskmanager`
`management_CR-ca`	`management_CR-random-postgres-pgbouncer`	server	`management_CR-random-postgres-pgbouncer`	`postgres-pgbouncer`
`management_CR-ca`	`management_CR-natscluster-mgmt`	clientserver	`management_CR-natscluster-mgmt`	`natscluster`
`management_CR-ca`	`pgbouncer`	client	`management_CR-db-client-pgbouncer`	`postgres-pgbouncer`
`management_CR-ca`	`postgres`	client	`management_CR-db-client-postgres`	`apim` `hub` `lur` `portal_CR-proxy` `taskmanager` `postgres-pgbouncer`
`management_CR-ca`	`postgres-operator`	server	`pgo.tls`	`postgres-operator`
`management_CR-ca`	`replicator`	client	`management_CR-db-client-replicator`	`management_CR-tunnel`
`portal_CR-ca`	`portal_CR-client`	client	`portal_CR-client`	`portal_CR-db` `portal_CR-www` `portal_CR-nginx` In a stand-alone, single data center deployment, no restart is needed (pods pick up the new secret and restart any internal processes automatically). In a two data center configuration or a Cloud Pak for Integration deployment, you must restart the pods manually (in both data centers if applicable) within 5-minutes of the update to avoid encountering (recoverable) errors.
`portal_CR-ca`	`portal_CR-server`	server	`portal_CR-server` + dynamically generated server cert for each `portal_CR-db` pod	`portal_CR-db-0` `portal_CR-db-1` `portal_CR-db-2` `portal_CR-www` In a stand-alone, single data center deployment, no restart is needed (pods pick up the new secret and restart any internal processes automatically). In a two data center configuration or a Cloud Pak for Integration deployment, you must restart the pods manually (in both data centers if applicable) within 5-minutes of the update to avoid encountering (recoverable) errors.

¹ Note that some of these pods might not exist on your deployment, depending on what features are installed.