TLS certificates organized by usage

Update this certificate with kubectl. When updated, all child certificates must also be updated by deleting their corresponding secrets. See ingress-ca renewal.

The ingress-ca certificate is also stored in the management subsystem database. It is visible from the Cloud Manager UI, in the truststores of the analytics, gateway, event gateway, and portal default TLS client profiles. When the management subsystem apim pod is restarted the certificate is reloaded into the database from the Kubernetes ingress-ca certificate. Do not attempt to update this certificate from the Cloud Manager UI.

In 2DCDR deployments, and when you have subsystems in different namespaces, it is necessary to manually copy the ingress-ca certificate from the management subsystem to the other subsystems. Steps are provided in the 2DCDR and multi-namespace install sections of this documentation.

If this certificate is updated, and you have a portal deployed, then restart the portal-www pods for the update to take effect.

Client certificate for communications with the gateway service. Restart the apim and taskmanager pods after update. This certificate must have the same CA as the gwv6-manager-endpoint or gw-gateway-manager certificate on the gateway.

This certificate is loaded by the management subsystem into the Gateway management client 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 gateway, then create a new profile and specify it when you register the gateway service.

The gatewayManager endpoint certificate. This is the server certificate on the gateway director endpoint, which the management subsystem communicates with.

This certificate must be signed by the same CA as the gateway-client-client certificate on management subsystem

If you update this certificate, then all gateway pods are restarted automatically.

Update this certificate with kubectl. When updated, all child certificates must also be updated by deleting their corresponding secrets. See ingress-ca renewal.

The ingress-ca certificate is also stored in the management subsystem database. It is visible from the Cloud Manager UI, in the truststores of the analytics, gateway, event gateway, and portal default TLS client profiles. When the management subsystem apim pod is restarted the certificate is reloaded into the database from the Kubernetes ingress-ca certificate. Do not attempt to update this certificate from the Cloud Manager UI.

In 2DCDR deployments, and when you have subsystems in different namespaces, it is necessary to manually copy the ingress-ca certificate from the management subsystem to the other subsystems. Steps are provided in the 2DCDR and multi-namespace install sections of this documentation.

If this certificate is updated, and you have a portal deployed, then restart the portal-www pods for the update to take effect.

For a two data center disaster recovery deployment, both data centers must have an identical subject name. For example, both data centers subject name could be CN=portal-admin-client, or they could both be CN=ptl-adm-client, O=cert-manager, but they must be identical.

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.

Server certificate used on the portalAdminEndpoint. The management subsystem communicates with the portal subsystem on this endpoint. The corresponding client certificate used in the management to portal communication is the portal-admin-client certificate.

This certificate must have the same CA as the portal-admin-client certificate on the management subsystem.

This certificate is used by the portal-nginx pod.

Update this certificate with kubectl. When updated, all child certificates must also be updated by deleting their corresponding secrets. See ingress-ca renewal.

The ingress-ca certificate is also stored in the management subsystem database. It is visible from the Cloud Manager UI, in the truststores of the analytics, gateway, event gateway, and portal default TLS client profiles. When the management subsystem apim pod is restarted the certificate is reloaded into the database from the Kubernetes ingress-ca certificate. Do not attempt to update this certificate from the Cloud Manager UI.

In 2DCDR deployments, and when you have subsystems in different namespaces, it is necessary to manually copy the ingress-ca certificate from the management subsystem to the other subsystems. Steps are provided in the 2DCDR and multi-namespace install sections of this documentation.

If this certificate is updated, and you have a portal deployed, then restart the portal-www pods for the update to take effect.

• The same CA as the server certificate analytics-ai-endpoint on the analytics subsystem.
• The common name must match the spec.clientSubjectDN in the analytics CR:

  kubectl describe cert analytics-admin-client
  
  Spec:
    Common Name:  a7s-ing-client

  kubectl get a7s -o yaml
  
    spec:
      clientSubjectDN: CN=a7s-ing-client

For a two data center disaster recovery deployment, both data centers must have an identical subject name. For example, both data centers subject name could be CN=a7s-ingestion-client, or they could both be CN=a7s-ingestion-client, O=cert-manager, but they must be identical.

To update this certificate, use kubectl. Restart the apim, taskmanager, and analytics-proxy pods after the update. This certificate is also used by the gateways for sending API events to the analytics subsystem. The updated certificate is sent by the management subsystem to the gateways, it is not necessary to restart any gateway pods.

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.

Server certificate used on the analytics ingestion endpoint, in the mtls-gw pod. Management and gateway subsystems communicate with the analytics subsystem on this endpoint. The client certificates that are used by the management and gateway subsystems must use the same CA certificate as the analytics-ai-endpoint certificate.

If this certificate is updated, restart the mtls-gw pod for the update to take effect.

The server certificate used on the portalUIEndpoint. It is the server certificate that is presented to portal site users, and which their browser authenticates. If there is a problem with this certificate, then users see an error message about an invalid or insecure certificate in their browser when they access a portal site.

The default portal-web certificate is issued by the ingress-issuer, which has a self-signed root certificate. Portal users might see a browser warning about use of a self-signed certificate.

This certificate is used by the portal-web ingress (portal-web route on OpenShift).

Update this certificate with kubectl. When updated, all child certificates must also be updated by deleting their corresponding secrets. See ingress-ca renewal.

The ingress-ca certificate is also stored in the management subsystem database. It is visible from the Cloud Manager UI, in the truststores of the analytics, gateway, event gateway, and portal default TLS client profiles. When the management subsystem apim pod is restarted the certificate is reloaded into the database from the Kubernetes ingress-ca certificate. Do not attempt to update this certificate from the Cloud Manager UI.

In 2DCDR deployments, and when you have subsystems in different namespaces, it is necessary to manually copy the ingress-ca certificate from the management subsystem to the other subsystems. Steps are provided in the 2DCDR and multi-namespace install sections of this documentation.

If this certificate is updated, and you have a portal deployed, then restart the portal-www pods for the update to take effect.

• The same CA as the server certificate analytics-ai-endpoint on the analytics subsystem.
• The common name must match the spec.clientSubjectDN in the analytics CR:

  kubectl describe cert analytics-admin-client
  
  Spec:
    Common Name:  a7s-ing-client

  kubectl get a7s -o yaml
  
    spec:
      clientSubjectDN: CN=a7s-ing-client

For a two data center disaster recovery deployment, both data centers must have an identical subject name. For example, both data centers subject name could be CN=a7s-ingestion-client, or they could both be CN=a7s-ingestion-client, O=cert-manager, but they must be identical.

To update this certificate, use kubectl. Restart the apim, taskmanager, and analytics-proxy pods after the update. This certificate is also used by the gateways for sending API events to the analytics subsystem. The updated certificate is sent by the management subsystem to the gateways, it is not necessary to restart any gateway pods.

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 a two data center disaster recovery deployment, both data centers must have an identical subject name. For example, both data centers subject name could be CN=portal-admin-client, or they could both be CN=ptl-adm-client, O=cert-manager, but they must be identical.

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.

Client certificate for communications with the gateway service. Restart the apim and taskmanager pods after update. This certificate must have the same CA as the gwv6-manager-endpoint or gw-gateway-manager certificate on the gateway.

This certificate is loaded by the management subsystem into the Gateway management client 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 gateway, then create a new profile and specify it when you register the gateway service.

This certificate must contain the DNS Subject Alternative Name of this data center's hostname and must be valid for the spec.multiSiteHA.replicationEndpoint defined in the management CR.

Server certificate used on the analytics ingestion endpoint, in the mtls-gw pod. Management and gateway subsystems communicate with the analytics subsystem on this endpoint. The client certificates that are used by the management and gateway subsystems must use the same CA certificate as the analytics-ai-endpoint certificate.

If this certificate is updated, restart the mtls-gw pod for the update to take effect.

Server certificate used on the portalAdminEndpoint. The management subsystem communicates with the portal subsystem on this endpoint. The corresponding client certificate used in the management to portal communication is the portal-admin-client certificate.

This certificate must have the same CA as the portal-admin-client certificate on the management subsystem.

This certificate is used by the portal-nginx pod.

The server certificate used on the portalUIEndpoint. It is the server certificate that is presented to portal site users, and which their browser authenticates. If there is a problem with this certificate, then users see an error message about an invalid or insecure certificate in their browser when they access a portal site.

The default portal-web certificate is issued by the ingress-issuer, which has a self-signed root certificate. Portal users might see a browser warning about use of a self-signed certificate.

This certificate is used by the portal-web ingress (portal-web route on OpenShift).

2DCDR deployments only. Client certificate that is used in the warm-standby data center's <remote-sitename>-www and <remote-sitename>-db pods to connect to the active data center.

This certificate is used by all the portal pods related to 2DCDR replication: portal-db-remote, portal-www-remote, and portal-tunnel.

2DCDR deployments only. Server certificate used in the active data center's <portal_CR>-tunnel pod, the counterpart to the ptl-replication-client certificate.

This certificate must contain the DNS Subject Alternative Name of this data center's hostname and must be valid for the spec.multiSiteHA.replicationEndpoint defined in the portal CR.

This certificate is used by all the portal pods related to 2DCDR replication: portal-db-remote, portal-www-remote, and portal-tunnel.

This certificate secures the communication between gateways in your gateway cluster.

If you update this certificate, then restart your gateway pods. See Changing the secret for gateway peering.

The gatewayManager endpoint certificate. This is the server certificate on the gateway director endpoint, which the management subsystem communicates with.

This certificate must be signed by the same CA as the gateway-client-client certificate on management subsystem

If you update this certificate, then all gateway pods are restarted automatically.

This certificate is also used as the CA for REST API calls to the management subsystem from the other subsystems, when using in-cluster communication. See In-cluster service communication between subsystems

If this certificate is updated, then the storage and warehouse pods restart automatically. You must manually restart the director and ingestion pods.

*.<namespace>
*.<namespace>.svc
*.<namespace>.svc.cluster.local
*.<instance name>-server.<namespace>.svc
*.<instance name>-server.<namespace>.svc.cluster.local
<instance name>-server
<instance name>-storage
<instance name>-director
<instance name>-ingestion
<instance name>-mtls-gw
<instance name>-storage-os-master
<instance name>-warehouse

If this certificate is updated, then the storage and warehouse pods restart automatically. You must manually restart the director and ingestion pods.

The issuer for the portal-client and portal-server certificates. Communication between portal subsystem pods fails if there is a problem with this certificate.

This certificate is used by all portal pods.

Client certificate used in communication between portal subsystem pods. Communication between portal subsystem pods fails if there is a problem with this certificate.

This certificate is used by all portal pods.

Server certificate used in communication between portal subsystem pods. Communication between portal subsystem pods fails if there is a problem with this certificate.

*.<namespace>
*.<namespace>.svc
*.<namespace>.svc.cluster.local
*.<instance name>-server.<namespace>.svc
*.<instance name>-server.<namespace>.svc.cluster.local
<instance name>-server
*.<instance name>-<site name>-db-all.<namespace>.svc
*.<instance name>-<site name>-www-all.<namespace>.svc
*.<instance name>-<site name>-db-all.<namespace>.svc.cluster.local
*.<instance name>-<site name>-www-all.<namespace>.svc.cluster.local
*.<namespace>.svc.cluster.local
<instance name>-db
#<remote portal CR name>-db # For 2DCDR only.

This certificate is used by all portal pods.