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 Update system-local-ca or Migrate 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 |
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.
