HTTPS and Certificates Management Overview

Certificates are required for secure HTTPS access and authentication on StarlingX platform.

This table lists all the platform certificates, and indicates which certificates are automatically created/renewed by the system versus which certificates must be manually created/renewed by the system administrator.

Platform certificates that are associated with optional platform components are only present if the optional platform component is configured (e.g. OIDC).

Platform certificates that are associated with Distributed Cloud are only present on DC SystemController systems or DC Subclouds.

Certificate

Description

Auto Created

Renewal Status

Etcd:

etcd Root CA certificate

Certificate that signs etcd server and client certificates, and kube-apiserver etcd client certificates

Yes

NOT AUTO-RENEWED; Default expiry is set at 10 years

etcd server certificate

Certificate used by etcd server to identify itself over HTTPS. Services such as kube-apiserver that access etcd verify this serving certificate with etcd Root CA certificate.

Yes

auto-renewed by cron job

etcd client certificate

Certificate used by clients to identify themselves while connecting to etcd by HTTPS

Yes

auto-renewed by cron job

kube-apiserver-etcd-client certificate

Certificate used by kube-apiserver to identify itself while connecting to etcd by HTTPS

Yes

auto-renewed by cron job

Kubernetes:

Kubernetes-root-ca

Kubernetes root CA certificate used to sign all other K8s server and client certificates

Yes

NOT AUTO-RENEWED; Default expiry is set at 10 years; MUST be renewed via CLI.

Cluster Admin client certificate used by kubectl

Client certificate used to access kubernetes-admin credentials for kubernetes API

Yes

auto-renewed by cron job

kube-controller-manager client certificate

Client certificate used by kube-controller-manager pod to identify itself to kube-apiserver

Yes

auto-renewed by cron job

kube-scheduler client certificate

Client certificate used by kube-scheduler pod to identify itself to kube-apiserver

Yes

auto-renewed by cron job

kube-apiserver certificate

Certificate used by kube-apiserver to identify itself over HTTPS. Clients connecting to kube-apiserver verify this certificate using kubernetes root CA certificate.

Yes

auto-renewed by cron job

kube-apiserver-kubelet client certificate

Kube-apiserver’s client certificate used for communication with kubelet

Yes

auto-renewed by cron job

kubelet client certificate

Client certificate used by kubelet to identify itself while connecting to kube-apiserver

Yes

auto-renewed by kubelet. Feature enabled by default

front-proxy-client

Client certificate signed by front-proxy root CA certificate. It is used by kube-apiserver/aggregator to connect to aggregated apiserver (extension APIserver).

Yes

front-proxy-client: auto-renewed by cron job

front-proxy-ca

The front-proxy Root CA certificate

Yes

front-proxy-ca: NOT AUTO-RENEWED; Default expiry is set at 10 years

StarlingX

system-local-ca

The CA certificate used to create Cert-Manager ClusterIssuer for signing a variety of StarlingX server certificates For Laboratory environment, K8s Root CA Certificate is used by default. For product environment, the CA certificate should be set to an Intermediate CA Cert/Key that has been signed by an external public Root CA. For information on how to update system-local.ca, see Migrate/Update Platform Certificates to use Cert Manager.

Yes

NOT AUTO-RENEWED. MUST be renewed via CLI

system-openldap-local-certificate

Certificate used by OpenLDAP server to identify itself over HTTPS. It is typically signed by system-local-ca. Services such as SSH/SSSD that access OpenLDAP verify this serving certificate with system-local-ca.

Yes

auto-renewed by system

ssl(restapi/gui)/system-restapi-gui-certificate

Certificate used by StarlingX RESTAPI endpoints and GUI (Horizon) to identify themselves over HTTPS. It is typically signed by system-local-ca. Services such as external RESTAPI clients or external browsers that access StarlingX RESTAPI endpoints and/or StarlingX GUI (Horizon) verify this serving certificate with system-local-ca.

Yes (But the auto-created certificate is self-signed and should be changed)

auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with system certificate-install .., must be renewed via CLI

docker_registry/system-registry-local-certificate

Certificate used by Docker distribution server (registry.local ) to identify itself over HTTPS.

It is typically signed by system-local-ca. Services such as internal and/or external clients of registry that access registry.local verify this serving certificate with system-local-ca.

Yes (But the auto-created certificate is self-signed and should be changed)

auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with system certificate-install .., must be renewed via CLI

OIDC:

OIDC Client and Dex Server Certificate/oidc-auth-apps-certificate

Certificate used by both the OIDC client server and the DEX OIDC server to identify themselves over HTTPS.

It is typically signed by system-local-ca. Services such as external clients that access OIDC client server/DEX OIDC server verify this serving certificate with system-local-ca.

No

auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with an externally generated certificate. MUST be renewed via CLI.

OIDC Client and Dex Server CA certificate

The CA certificate that signs the OIDC client server certificate and the DEX OIDC server certificate. In the recommended configurations, the CA certificate is system-local-ca.

No

NOT AUTO-RENEWED. MUST be renewed via CLI.

OIDC Remote WAD CA Certificate

The CA certificate that signs the remote Windows Active Directory configured in the oidc-auth-apps application. The DEX server uses this CA certificate to validate the remote Windows Active Directory’s server certificate.

No

NOT AUTO-RENEWED. MUST be renewed via CLI.

Vault:

Vault Server Certificate

Certificate used by Vault server to identify itself over HTTPS. It is typically signed by system-local-ca. Vault RESTAPIs or applications using Vault verify this serving certificate with system-local-ca.

Yes

NOT AUTO-RENEWED; MUST be renewed via CLI.

Vault Root CA certificate

The CA certificate that signs the Vault Server certificate. In the recommended configurations, the CA certificate is system-local-ca.

Yes

NOT AUTO-RENEWED; MUST be renewed via CLI.

Portieris:

Portieris Server Certificate

Certificate used by Portieris Admission-Control server to identify itself over HTTPS. It is typically signed by system-local-ca. The Portieris kubernetes admission webhook, which makes request to Portieris Admission-Control server verifies this serving certificate with system-local-ca.

Yes

Auto renewed by cert-manager; BUT CUSTOMER MUST restart Portieris after the certificate is renewed

Portieris remote registry and notary server CA Certificate

The CA certificate that signs the Portieris Admission Control server certificate. In the recommended configurations, the CA certificate is system-local-ca.

No

NOT AUTO-RENEWED; CUSTOMER MUST renew via CLIs

DC Admin Endpoints:

DC-AdminEp-RootCA

The CA certificate that signs the dc-adminep-certificate. On SystemController, it is called dc-adminep-root-ca-certificate. On subcloud, it is called sc-adminep-root-ca-certificate.

Yes

auto-renewed

DC-AdminEp-InterCA

Signed by adminep-rootCA. On SystemController, it is called dc-adminep-inter-ca-certificate. On subcloud, it is called sc-adminep-inter-ca-certificate.

Yes

auto-renewed

DC-AdminEp-Server

On SystemController, it is called dc-adminep-certificate. On subcloud, it is called sc-adminep-certificate signed by interCA.

Yes

auto-renewed

System trusted CA Certificates (ssl_ca)

One or more (typically external) CA certificates to identify remote servers. Example: when using an external Container Registry, the certificate of the CA that signed the external Container Registry’s certificate must be configured to validate the identity of the external Container Regsitry.

No

NOT AUTO-RENEWED as these are certificates that are not necessarily owned by the platform

Where:

  • Auto created: the certificate is generated during system deployment or triggered by certain operations.

  • Renewal Status: whether the certificate is renewed automatically by the system when expiry date approaches.

The specific certificates, and details such as expiration date, that are present on a StarlingX system can be displayed with a local script, sudo show-certs.sh, see Display Certificates Installed on a System.

StarlingX monitors the installed certificates on the system by raising alarms for expired certificates and certificates that will expire soon, see Expiring-Soon and Expired Certificate Alarms.

The following sections provide details on managing these certificates.

For further information about certificates expiration date or other certificates information, see Display Certificates Installed on a System.

In addition, StarlingX monitors the installed certificates on the system by raising alarms for expire-soon certificates and for expired certificates on the system, see Expiring-Soon and Expired Certificate Alarms.