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 / Synonyms |
System Type |
Description |
Auto Created |
Default Duration |
Renewal Mechanism |
Renew Before Time |
Impact of Certificate Expiry |
|---|---|---|---|---|---|---|---|
Etcd: |
|||||||
etcd Root CA certificate |
ALL |
Certificate that signs etcd server and client certificates, and kube-apiserver etcd client certificates |
Yes |
10 years |
NOT AUTO-RENEWED; Default expiry is set at 10 years. When an override is provided, it is recommended to to use a CA certificate with a long remaining validity (~5-10 years). |
Manual (alarmed within 30 days of expiry) |
K8s cluster is not usable which will likely impact service of K8s workloads |
etcd server certificate |
ALL |
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 |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
etcd client certificate |
ALL |
Certificate used by clients to identify themselves while connecting to etcd by HTTPS |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
kube-apiserver-etcd-client certificate |
ALL |
Certificate used by kube-apiserver to identify itself while connecting to etcd by HTTPS |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
Kubernetes: |
|||||||
Kubernetes-root-ca |
ALL |
Kubernetes root CA certificate used to sign all other K8s server and client certificates. This certificate is automatically generated during bootstrap, with a default expiration period of 10 years. While bootstrap overrides remain supported, their usage is deprecated and will be phased out in future releases. |
Yes |
10 years |
NOT AUTO-RENEWED; Default expiry is set at 10 years; MUST be renewed via CLI. When an override is provided, it is recommended to to use a CA certificate with a long remaining validity (~5-10 years). |
Manual (alarmed within 30 days of expiry) |
K8s cluster is not usable which will likely impact service of K8S workloads |
Cluster Admin client certificate used by kubectl / admin.conf |
ALL |
Client certificate used to access kubernetes-admin credentials for kubernetes API used by kubectl and other python API clients. Its privileges are determined by the built-in cluster-admin ClusterRole. |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not accessible by sysadmin (via kubectl) and platform services, impacting maintenance operations. |
Cluster Super Admin client certificate / super-admin.conf |
ALL |
The client certificate provides access to the kubernetes-super-admin credentials—a break-glass superuser group that bypasses the standard authorization layer (e.g., RBAC). It is reserved for emergency recovery scenarios, such as when RBAC is misconfigured or non-functional. |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
Ability to recover cluster in case of RBAC misconfiguration impacted. |
kube-controller-manager client certificate/controller-manager.conf |
ALL |
Client certificate used by kube-controller-manager pod to identify itself to kube-apiserver |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
kube-scheduler client certificate / scheduler.conf |
ALL |
Client certificate used by kube-scheduler pod to identify itself to kube-apiserver |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
The currently running pods and workloads will not be affected, however new pods will not be scheduled on the k8s node where the certificate has expired |
kube-apiserver certificate |
ALL |
The certificate is used by the kube-apiserver to authenticate itself internally over HTTPS. Internal clients verify this certificate using the Kubernetes root CA. For external clients, the ssl(restapi/gui)/system-restapi-gui-certificate is presented to identify the system’s kube-apiserver. This approach allows external clients to rely solely on the system-local-ca to validate all HTTPS-based endpoints exposed externally |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
Clients trying to connect to K8s REST APIs will fail. As some of these internal clients are K8s services, K8s cluster is not usable which will likely impact service of K8s workloads |
kube-apiserver-kubelet client certificate |
ALL |
Kube-apiserver’s client certificate used for communication with kubelet |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
kubelet client certificate |
ALL |
Client certificate used by kubelet to identify itself while connecting to kube-apiserver |
Yes |
1 year |
auto-renewed by kubelet. Feature enabled by default |
30 days before expiry |
K8s cluster is not usable which will likely impact service of K8s workloads |
front-proxy-client |
ALL |
Client certificate signed by front-proxy root CA certificate. It is used by kube-apiserver/aggregator to connect to aggregated apiserver (extension APIserver). |
Yes |
1 year |
auto-renewed by cron job |
30 days before expiry |
Only K8s Aggregated APIs (example: metrics server API) fail |
front-proxy-ca |
ALL |
The front-proxy Root CA certificate |
Yes |
10 years |
NOT AUTO-RENEWED; Default expiry is set at 10 years |
Manual (alarmed within 30 days of expiry) |
Only K8s Aggregated APIs (example: metrics server API) fail |
StarlingX |
|||||||
system-local-ca |
ALL |
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 |
Yes |
10 years |
NOT AUTO-RENEWED. MUST be renewed via CLI. It is recommended to to use a CA certificate with a long remaining validity (~5-10 years). |
Manual (alarmed within 30 days of expiry) |
External HTTPS clients trying to connect to StarlingX REST APIs, registry.local, and OIDC Client / DEX Server will fail |
system-openldap-local-certificate |
standalone, SystemController |
Certificate used by OpenLDAP server to identify itself over HTTPS. It is signed by system-local-ca. Services such as SSH/SSSD that access OpenLDAP verify this serving certificate with system-local-ca. |
Yes |
90 days (cert-manager) |
auto-renewed by cert-manager, as long as system-local-ca is valid |
15 days before expiry (cert-manager) |
Authentication of StarlingX local LDAP user IDs will fail |
ssl(restapi/gui)/system-restapi-gui-certificate |
ALL |
Certificate used by StarlingX RESTAPI endpoints, GUI (Horizon), and K8s kube-apiserver (to external clients through HAproxy) to identify itself over HTTPS. It is signed by system-local-ca. Services such as external RESTAPI clients or external browsers that access StarlingX RESTAPI endpoints, (i.e. kube-api-server), and / or StarlingX GUI (Horizon), verify this serving certificate with system-local-ca. |
Yes |
90 days (cert-manager) |
auto-renewed by cert-manager, as long as system-local-ca is valid |
15 days before expiry (cert-manager) |
External HTTPS clients trying to connect to StarlingX REST APIs, kube-apiserver, and horizon will fail |
docker_registry/system-registry-local-certificate |
ALL |
Certificate used by Docker distribution server (registry.local ) to identify itself over HTTPS. It is 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 |
90 days (cert-manager) |
auto-renewed by cert-manager, as long as system-local-ca is valid |
15 days before expiry (cert-manager) |
External HTTPS clients trying to connect to registry.local will fail |
OIDC: |
|||||||
OIDC Client and Dex Server Certificate/oidc-auth-apps-certificate |
Typically, standalone, SystemController |
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 authentication will fail |
||
OIDC Client and Dex Server CA certificate |
Optional, but typically standalone, SystemController |
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 |
< system-local-ca > |
NOT AUTO-RENEWED. MUST be renewed via CLI. |
< system-local-ca > |
OIDC authentication will fail |
OIDC Remote WAD CA Certificate |
Optional, but typically standalone, SystemController |
The CA certificate that signs the remote Windows Active Directory
configured in the |
No |
NA (not owned by Platform) |
NOT AUTO-RENEWED. MUST be renewed via CLI. |
NA (not owned by Platform) |
OIDC authentication will fail |
Vault: |
|||||||
Vault Server Certificate |
Optional, but typically standalone, subclouds |
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 |
90 days (cert-manager) |
NOT AUTO-RENEWED; MUST be renewed via CLI. |
15 days before expiry (cert-manager) |
Pod workloads’ interactions with Vault server will fail |
Vault Root CA certificate |
Optional, but typically standalone, subclouds |
The CA certificate that signs the Vault Server certificate. In the recommended configurations, the CA certificate is system-local-ca. |
Yes |
< system-local-ca > |
NOT AUTO-RENEWED; MUST be renewed via CLI |
< system-local-ca > |
Pod workloads’ interactions with Vault server will fail |
Portieris: |
|||||||
Portieris Server Certificate |
Optional, but typically ALL |
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 |
90 days (cert-manager) |
Auto renewed by cert-manager; BUT CUSTOMER MUST restart Portieris after the certificate is renewed |
15 days before expiry (cert-manager) |
ALL new pods will likely fail because they will not be able to validate their authorization to pull their container image from the registry |
Portieris remote registry and notary server CA Certificate |
Optional, but typically ALL |
The CA certificate that signs the Portieris Admission Control server certificate. In the recommended configurations, the CA certificate is system-local-ca. |
No |
NA (not owned by Platform) |
NOT AUTO-RENEWED; CUSTOMER MUST renew via CLIs |
NA (not owned by Platform) |
ALL new pods will likely fail because they will not be able to validate their authorization to pull their container image from the registry |
DC Admin Endpoints: |
|||||||
DC-AdminEp-RootCA / dc-adminep-root-ca-certificate / sc-adminep-root-ca-certificate |
SystemController |
The Root CA certificate that signs the DC-AdminEp-Server certificates of the SystemController and signs the DC-AdminEp-InterCA certificates of the subcloud |
Yes |
5 years |
auto-renewed by cert-manager |
30 days before expiry |
SystemController to subcloud communication will fail. Subcloud will become unmanageable from SystemController |
DC-AdminEp-InterCA / <uuid>-adminep-ca-certificate / sc-adminep-ca-certificate |
Subclouds |
Signed by DC-AdminEp-RootCA. This Intermediate CA certificate signs the DC-AdminEp-Server certificates of subclouds |
Yes |
1 year |
auto-renewed by cert-manager, as long as DC-AdminEp-RootCA is valid |
30 days before expiry |
SystemController to subcloud communication will fail. Subcloud will become unmanageable from SystemController |
DC-AdminEp-Server / dc-adminep-certificate / sc-adminep-certificate |
SystemController, Subclouds |
The certificate used by SystemController and subclouds to identify themselves over HTTPS StarlingX administrator endpoints used for SystemController to subcloud messaging. Signed by either DC-AdminEp-RootCA on SystemController or DC-AdminEp-InterCA on subclouds |
Yes |
6 months |
auto-renewed by cert-manager, as long as sc-adminep-ca-certificate is valid |
30 days before expiry |
SystemController to subcloud communication will fail. Subcloud will become unmanageable from SystemController |
System trusted CA Certificates (ssl_ca) |
ALL |
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 |
NA (not owned by Platform) |
NOT AUTO-RENEWED as these are certificates that are not necessarily owned by the platform |
NA (not owned by Platform) |
StarlingX will not be able to communicate with server related to this trusted CA. For example, it will not be able to pull images from a remote registry |
IPsec certificate |
This certificate is utilized by StrongSwan/IPsec to secure and authenticate data exchanged between nodes across the internal management network. It is signed by the system-local-ca and is automatically generated during the initial IPsec authentication process when new nodes are added to the system. |
Yes |
90 days (cert-manager) |
IPsec certificate is auto-renewed by cron job, as long as system-local-ca is valid |
15 days before expiry (cert-manager) |
Network traffic over management network is interrupted |
Where:
Auto created: the certificate is generated during system deployment or triggered by certain operations.
Renewal Mechanism: 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 using system certificate-list or 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.
