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 at bootstrap through overrides or through the proper update procedure. For information on system-local-ca, see System Local CA Issuer.		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	auto-renewed 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	auto-renewed 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 Registry.		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:

• StarlingX REST API Applications and the Web Administration Server Certificate

• Kubernetes Certificates

• Configure Docker Registry Certificate

• System Trusted CA 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.