Chapter 4. Certificate types and descriptions
Chapter 4. Certificate types and descriptions 4.1. User-provided certificates for the API server 4.1.1. Purpose The API server is accessible by clients external to the cluster at api.<cluster_name>.<base_domain> . You might want clients to access the API server at a different hostname or without the need to distribute the cluster-managed certificate authority (CA) certificates to the clients. The administrator must set a custom default certificate to be used by the API server when serving content. 4.1.2. Location The user-provided certificates must be provided in a kubernetes.io/tls type Secret in the openshift-config namespace. Update the API server cluster configuration, the apiserver/cluster resource, to enable the use of the user-provided certificate. 4.1.3. Management User-provided certificates are managed by the user. 4.1.4. Expiration API server client certificate expiration is less than five minutes. User-provided certificates are managed by the user. 4.1.5. Customization Update the secret containing the user-managed certificate as needed. Additional resources Adding API server certificates 4.2. Proxy certificates 4.2.1. Purpose Proxy certificates allow users to specify one or more custom certificate authority (CA) certificates used by platform components when making egress connections. The trustedCA field of the Proxy object is a reference to a config map that contains a user-provided trusted certificate authority (CA) bundle. This bundle is merged with the Red Hat Enterprise Linux CoreOS (RHCOS) trust bundle and injected into the trust store of platform components that make egress HTTPS calls. For example, image-registry-operator calls an external image registry to download images. If trustedCA is not specified, only the RHCOS trust bundle is used for proxied HTTPS connections. Provide custom CA certificates to the RHCOS trust bundle if you want to use your own certificate infrastructure. The trustedCA field should only be consumed by a proxy validator. The validator is responsible for reading the certificate bundle from required key ca-bundle.crt and copying it to a config map named trusted-ca-bundle in the openshift-config-managed namespace. The namespace for the config map referenced by trustedCA is openshift-config : apiVersion: v1 kind: ConfigMap metadata: name: user-ca-bundle namespace: openshift-config data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- Custom CA certificate bundle. -----END CERTIFICATE----- Additional resources Configuring the cluster-wide proxy 4.2.2. Managing proxy certificates during installation The additionalTrustBundle value of the installer configuration is used to specify any proxy-trusted CA certificates during installation. For example: USD cat install-config.yaml Example output ... proxy: httpProxy: http://<username:password@proxy.example.com:123/> httpsProxy: http://<username:password@proxy.example.com:123/> noProxy: <123.example.com,10.88.0.0/16> additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_HTTPS_PROXY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ... 4.2.3. Location The user-provided trust bundle is represented as a config map. The config map is mounted into the file system of platform components that make egress HTTPS calls. Typically, Operators mount the config map to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem , but this is not required by the proxy. A proxy can modify or inspect the HTTPS connection. In either case, the proxy must generate and sign a new certificate for the connection. Complete proxy support means connecting to the specified proxy and trusting any signatures it has generated. Therefore, it is necessary to let the user specify a trusted root, such that any certificate chain connected to that trusted root is also trusted. If you use the RHCOS trust bundle, place CA certificates in /etc/pki/ca-trust/source/anchors . For more information, see Using shared system certificates in the Red Hat Enterprise Linux (RHEL) Securing networks document. 4.2.4. Expiration The user sets the expiration term of the user-provided trust bundle. The default expiration term is defined by the CA certificate itself. It is up to the CA administrator to configure this for the certificate before it can be used by OpenShift Container Platform or RHCOS. Note Red Hat does not monitor for when CAs expire. However, due to the long life of CAs, this is generally not an issue. However, you might need to periodically update the trust bundle. 4.2.5. Services By default, all platform components that make egress HTTPS calls will use the RHCOS trust bundle. If trustedCA is defined, it will also be used. Any service that is running on the RHCOS node is able to use the trust bundle of the node. 4.2.6. Management These certificates are managed by the system and not the user. 4.2.7. Customization Updating the user-provided trust bundle consists of either: updating the PEM-encoded certificates in the config map referenced by trustedCA, or creating a config map in the namespace openshift-config that contains the new trust bundle and updating trustedCA to reference the name of the new config map. The mechanism for writing CA certificates to the RHCOS trust bundle is exactly the same as writing any other file to RHCOS, which is done through the use of machine configs. When the Machine Config Operator (MCO) applies the new machine config that contains the new CA certificates, it runs the program update-ca-trust afterwards and restarts the CRI-O service on the RHCOS nodes. This update does not require a node reboot. Restarting the CRI-O service automatically updates the trust bundle with the new CA certificates. For example: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 50-examplecorp-ca-cert spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= mode: 0644 overwrite: true path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt The trust store of machines must also support updating the trust store of nodes. 4.2.8. Renewal There are no Operators that can auto-renew certificates on the RHCOS nodes. Note Red Hat does not monitor for when CAs expire. However, due to the long life of CAs, this is generally not an issue. However, you might need to periodically update the trust bundle. 4.3. Service CA certificates 4.3.1. Purpose service-ca is an Operator that creates a self-signed CA when an OpenShift Container Platform cluster is deployed. 4.3.2. Expiration A custom expiration term is not supported. The self-signed CA is stored in a secret with qualified name service-ca/signing-key in fields tls.crt (certificate(s)), tls.key (private key), and ca-bundle.crt (CA bundle). Other services can request a service serving certificate by annotating a service resource with service.beta.openshift.io/serving-cert-secret-name: <secret name> . In response, the Operator generates a new certificate, as tls.crt , and private key, as tls.key to the named secret. The certificate is valid for two years. Other services can request that the CA bundle for the service CA be injected into API service or config map resources by annotating with service.beta.openshift.io/inject-cabundle: true to support validating certificates generated from the service CA. In response, the Operator writes its current CA bundle to the CABundle field of an API service or as service-ca.crt to a config map. As of OpenShift Container Platform 4.3.5, automated rotation is supported and is backported to some 4.2.z and 4.3.z releases. For any release supporting automated rotation, the service CA is valid for 26 months and is automatically refreshed when there is less than 13 months validity left. If necessary, you can manually refresh the service CA. The service CA expiration of 26 months is longer than the expected upgrade interval for a supported OpenShift Container Platform cluster, such that non-control plane consumers of service CA certificates will be refreshed after CA rotation and prior to the expiration of the pre-rotation CA. Warning A manually-rotated service CA does not maintain trust with the service CA. You might experience a temporary service disruption until the pods in the cluster are restarted, which ensures that pods are using service serving certificates issued by the new service CA. 4.3.3. Management These certificates are managed by the system and not the user. 4.3.4. Services Services that use service CA certificates include: cluster-autoscaler-operator cluster-monitoring-operator cluster-authentication-operator cluster-image-registry-operator cluster-ingress-operator cluster-kube-apiserver-operator cluster-kube-controller-manager-operator cluster-kube-scheduler-operator cluster-networking-operator cluster-openshift-apiserver-operator cluster-openshift-controller-manager-operator cluster-samples-operator cluster-storage-operator machine-config-operator console-operator insights-operator machine-api-operator operator-lifecycle-manager CSI driver operators This is not a comprehensive list. Additional resources Manually rotate service serving certificates Securing service traffic using service serving certificate secrets 4.4. Node certificates 4.4.1. Purpose Node certificates are signed by the cluster and allow the kubelet to communicate with the Kubernetes API server. They come from the kubelet CA certificate, which is generated by the bootstrap process. 4.4.2. Location The kubelet CA certificate is located in the kube-apiserver-to-kubelet-signer secret in the openshift-kube-apiserver-operator namespace. 4.4.3. Management These certificates are managed by the system and not the user. 4.4.4. Expiration Node certificates are automatically rotated after 292 days and expire after 365 days. 4.4.5. Renewal The Kubernetes API Server Operator automatically generates a new kube-apiserver-to-kubelet-signer CA certificate at 292 days. The old CA certificate is removed after 365 days. Nodes are not rebooted when a kubelet CA certificate is renewed or removed. Cluster administrators can manually renew the kubelet CA certificate by running the following command: USD oc annotate -n openshift-kube-apiserver-operator secret kube-apiserver-to-kubelet-signer auth.openshift.io/certificate-not-after- Additional resources Working with nodes 4.5. Bootstrap certificates 4.5.1. Purpose The kubelet, in OpenShift Container Platform 4 and later, uses the bootstrap certificate located in /etc/kubernetes/kubeconfig to initially bootstrap. This is followed by the bootstrap initialization process and authorization of the kubelet to create a CSR . In that process, the kubelet generates a CSR while communicating over the bootstrap channel. The controller manager signs the CSR, resulting in a certificate that the kubelet manages. 4.5.2. Management These certificates are managed by the system and not the user. 4.5.3. Expiration This bootstrap certificate is valid for 10 years. The kubelet-managed certificate is valid for one year and rotates automatically at around the 80 percent mark of that one year. Note OpenShift Lifecycle Manager (OLM) does not update the bootstrap certificate. 4.5.4. Customization You cannot customize the bootstrap certificates. 4.6. etcd certificates 4.6.1. Purpose etcd certificates are signed by the etcd-signer; they come from a certificate authority (CA) that is generated by the bootstrap process. 4.6.2. Expiration The CA certificates are valid for 10 years. The peer, client, and server certificates are valid for three years. 4.6.3. Rotating the etcd certificate The etcd certificate automatically rotates using the etcd cluster Operator. However, if a certificate must be rotated before it is automatically rotated, you can manually rotate it. Procedure Make a backup copy of the current signer certificate by running the following command: USD oc get secret -n openshift-etcd etcd-signer -oyaml > signer_backup_secret.yaml Delete the existing signer certificate by running the following command: USD oc delete secret -n openshift-etcd etcd-signer Wait for the static pod roll out by running the following command. The static pod roll out can take a few minutes to complete. USD oc wait --for=condition=Progressing=False --timeout=15m clusteroperator/etcd 4.6.4. Removing an unused certificate authority from the bundle A manual rotation does not immediately update the trust bundle to remove the public key of a signer certificate. The public key of the signer certificate is removed at the expiration date, however if the public key must be removed before it expires, you can delete it. Procedure Delete the key by running the following command: USD oc delete configmap -n openshift-etcd etcd-ca-bundle Wait for the static pod rollout by running the following command. The bundle regenerates with the current signer certificate and all unknown or unused keys are deleted. USD oc adm wait-for-stable-cluster --minimum-stable-period 2m 4.6.5. etcd certificate rotation alerts and metrics signer certificates Two alerts inform users about pending etcd certificate expiration: etcdSignerCAExpirationWarning Occurs 730 days until the signer expires. etcdSignerCAExpirationCritical Occurs 365 days until the signer expires. These alerts track the expiration date of the signer certificate authorities in the openshift-etcd namespace. You can rotate the certificate for the following reasons: You receive an expiration alert. The private key is leaked. Important When a private key is leaked, you must rotate all of the certificates. There is an etcd signer for the OpenShift Container Platform metrics system. Substitute the following metrics parameters in Rotating the etcd certificate . etcd-metric-signer instead of etcd-signer etcd-metrics-ca-bundle instead of etcd-ca-bundle 4.6.6. Management These certificates are only managed by the system and are automatically rotated. 4.6.7. Services etcd certificates are used for encrypted communication between etcd member peers and encrypted client traffic. The following certificates are generated and used by etcd and other processes that communicate with etcd: Peer certificates: Used for communication between etcd members. Client certificates: Used for encrypted server-client communication. Client certificates are currently used by the API server only, and no other service should connect to etcd directly except for the proxy. Client secrets ( etcd-client , etcd-metric-client , etcd-metric-signer , and etcd-signer ) are added to the openshift-config , openshift-monitoring , and openshift-kube-apiserver namespaces. Server certificates: Used by the etcd server for authenticating client requests. Metric certificates: All metric consumers connect to proxy with metric-client certificates. Additional resources Restoring to a cluster state 4.7. OLM certificates 4.7.1. Management All certificates for Operator Lifecycle Manager (OLM) components ( olm-operator , catalog-operator , packageserver , and marketplace-operator ) are managed by the system. When installing Operators that include webhooks or API services in their ClusterServiceVersion (CSV) object, OLM creates and rotates the certificates for these resources. Certificates for resources in the openshift-operator-lifecycle-manager namespace are managed by OLM. OLM will not update the certificates of Operators that it manages in proxy environments. These certificates must be managed by the user using the subscription config. steps Configuring proxy support in Operator Lifecycle Manager 4.7.2. Additional resources Proxy certificates Replacing the default ingress certificate Updating the CA bundle 4.8. Aggregated API client certificates 4.8.1. Purpose Aggregated API client certificates are used to authenticate the KubeAPIServer when connecting to the Aggregated API Servers. 4.8.2. Management These certificates are managed by the system and not the user. 4.8.3. Expiration This CA is valid for 30 days. The managed client certificates are valid for 30 days. CA and client certificates are rotated automatically through the use of controllers. 4.8.4. Customization You cannot customize the aggregated API server certificates. 4.9. Machine Config Operator certificates 4.9.1. Purpose This certificate authority is used to secure connections from nodes to Machine Config Server (MCS) during initial provisioning. There are two certificates: . A self-signed CA, the MCS CA . A derived certificate, the MCS cert 4.9.1.1. Provisioning details OpenShift Container Platform installations that use Red Hat Enterprise Linux CoreOS (RHCOS) are installed by using Ignition. This process is split into two parts: An Ignition config is created that references a URL for the full configuration served by the MCS. For user-provisioned infrastucture installation methods, the Ignition config manifests as a worker.ign file created by the openshift-install command. For installer-provisioned infrastructure installation methods that use the Machine API Operator, this configuration appears as the worker-user-data secret. Important Currently, there is no supported way to block or restrict the machine config server endpoint. The machine config server must be exposed to the network so that newly-provisioned machines, which have no existing configuration or state, are able to fetch their configuration. In this model, the root of trust is the certificate signing requests (CSR) endpoint, which is where the kubelet sends its certificate signing request for approval to join the cluster. Because of this, machine configs should not be used to distribute sensitive information, such as secrets and certificates. To ensure that the machine config server endpoints, ports 22623 and 22624, are secured in bare metal scenarios, customers must configure proper network policies. Additional resources Machine Config Operator . About the OVN-Kubernetes network plugin 4.9.1.2. Provisioning chain of trust The MCS CA is injected into the Ignition configuration under the security.tls.certificateAuthorities configuration field. The MCS then provides the complete configuration using the MCS cert presented by the web server. The client validates that the MCS cert presented by the server has a chain of trust to an authority it recognizes. In this case, the MCS CA is that authority, and it signs the MCS cert. This ensures that the client is accessing the correct server. The client in this case is Ignition running on a machine in the initramfs. 4.9.1.3. Key material inside a cluster The MCS CA appears in the cluster as a config map in the kube-system namespace, root-ca object, with ca.crt key. The private key is not stored in the cluster and is discarded after the installation completes. The MCS cert appears in the cluster as a secret in the openshift-machine-config-operator namespace and machine-config-server-tls object with the tls.crt and tls.key keys. 4.9.2. Management At this time, directly modifying either of these certificates is not supported. 4.9.3. Expiration The MCS CA is valid for 10 years. The issued serving certificates are valid for 10 years. 4.9.4. Customization You cannot customize the Machine Config Operator certificates. 4.10. User-provided certificates for default ingress 4.10.1. Purpose Applications are usually exposed at <route_name>.apps.<cluster_name>.<base_domain> . The <cluster_name> and <base_domain> come from the installation config file. <route_name> is the host field of the route, if specified, or the route name. For example, hello-openshift-default.apps.username.devcluster.openshift.com . hello-openshift is the name of the route and the route is in the default namespace. You might want clients to access the applications without the need to distribute the cluster-managed CA certificates to the clients. The administrator must set a custom default certificate when serving application content. Warning The Ingress Operator generates a default certificate for an Ingress Controller to serve as a placeholder until you configure a custom default certificate. Do not use operator-generated default certificates in production clusters. 4.10.2. Location The user-provided certificates must be provided in a tls type Secret resource in the openshift-ingress namespace. Update the IngressController CR in the openshift-ingress-operator namespace to enable the use of the user-provided certificate. For more information on this process, see Setting a custom default certificate . 4.10.3. Management User-provided certificates are managed by the user. 4.10.4. Expiration User-provided certificates are managed by the user. 4.10.5. Services Applications deployed on the cluster use user-provided certificates for default ingress. 4.10.6. Customization Update the secret containing the user-managed certificate as needed. Additional resources Replacing the default ingress certificate 4.11. Ingress certificates 4.11.1. Purpose The Ingress Operator uses certificates for: Securing access to metrics for Prometheus. Securing access to routes. 4.11.2. Location To secure access to Ingress Operator and Ingress Controller metrics, the Ingress Operator uses service serving certificates. The Operator requests a certificate from the service-ca controller for its own metrics, and the service-ca controller puts the certificate in a secret named metrics-tls in the openshift-ingress-operator namespace. Additionally, the Ingress Operator requests a certificate for each Ingress Controller, and the service-ca controller puts the certificate in a secret named router-metrics-certs-<name> , where <name> is the name of the Ingress Controller, in the openshift-ingress namespace. Each Ingress Controller has a default certificate that it uses for secured routes that do not specify their own certificates. Unless you specify a custom certificate, the Operator uses a self-signed certificate by default. The Operator uses its own self-signed signing certificate to sign any default certificate that it generates. The Operator generates this signing certificate and puts it in a secret named router-ca in the openshift-ingress-operator namespace. When the Operator generates a default certificate, it puts the default certificate in a secret named router-certs-<name> (where <name> is the name of the Ingress Controller) in the openshift-ingress namespace. Warning The Ingress Operator generates a default certificate for an Ingress Controller to serve as a placeholder until you configure a custom default certificate. Do not use Operator-generated default certificates in production clusters. 4.11.3. Workflow Figure 4.1. Custom certificate workflow Figure 4.2. Default certificate workflow An empty defaultCertificate field causes the Ingress Operator to use its self-signed CA to generate a serving certificate for the specified domain. The default CA certificate and key generated by the Ingress Operator. Used to sign Operator-generated default serving certificates. In the default workflow, the wildcard default serving certificate, created by the Ingress Operator and signed using the generated default CA certificate. In the custom workflow, this is the user-provided certificate. The router deployment. Uses the certificate in secrets/router-certs-default as its default front-end server certificate. In the default workflow, the contents of the wildcard default serving certificate (public and private parts) are copied here to enable OAuth integration. In the custom workflow, this is the user-provided certificate. The public (certificate) part of the default serving certificate. Replaces the configmaps/router-ca resource. The user updates the cluster proxy configuration with the CA certificate that signed the ingresscontroller serving certificate. This enables components like auth , console , and the registry to trust the serving certificate. The cluster-wide trusted CA bundle containing the combined Red Hat Enterprise Linux CoreOS (RHCOS) and user-provided CA bundles or an RHCOS-only bundle if a user bundle is not provided. The custom CA certificate bundle, which instructs other components (for example, auth and console ) to trust an ingresscontroller configured with a custom certificate. The trustedCA field is used to reference the user-provided CA bundle. The Cluster Network Operator injects the trusted CA bundle into the proxy-ca config map. OpenShift Container Platform 4.17 and newer use default-ingress-cert . 4.11.4. Expiration The expiration terms for the Ingress Operator's certificates are as follows: The expiration date for metrics certificates that the service-ca controller creates is two years after the date of creation. The expiration date for the Operator's signing certificate is two years after the date of creation. The expiration date for default certificates that the Operator generates is two years after the date of creation. You cannot specify custom expiration terms on certificates that the Ingress Operator or service-ca controller creates. You cannot specify expiration terms when installing OpenShift Container Platform for certificates that the Ingress Operator or service-ca controller creates. 4.11.5. Services Prometheus uses the certificates that secure metrics. The Ingress Operator uses its signing certificate to sign default certificates that it generates for Ingress Controllers for which you do not set custom default certificates. Cluster components that use secured routes may use the default Ingress Controller's default certificate. Ingress to the cluster via a secured route uses the default certificate of the Ingress Controller by which the route is accessed unless the route specifies its own certificate. 4.11.6. Management Ingress certificates are managed by the user. See Replacing the default ingress certificate for more information. 4.11.7. Renewal The service-ca controller automatically rotates the certificates that it issues. However, it is possible to use oc delete secret <secret> to manually rotate service serving certificates. The Ingress Operator does not rotate its own signing certificate or the default certificates that it generates. Operator-generated default certificates are intended as placeholders for custom default certificates that you configure. 4.12. Monitoring and OpenShift Logging Operator component certificates 4.12.1. Expiration Monitoring components secure their traffic with service CA certificates. These certificates are valid for 2 years and are replaced automatically on rotation of the service CA, which is every 13 months. If the certificate lives in the openshift-monitoring or openshift-logging namespace, it is system managed and rotated automatically. 4.12.2. Management These certificates are managed by the system and not the user. 4.13. Control plane certificates 4.13.1. Location Control plane certificates are included in these namespaces: openshift-config-managed openshift-kube-apiserver openshift-kube-apiserver-operator openshift-kube-controller-manager openshift-kube-controller-manager-operator openshift-kube-scheduler 4.13.2. Management Control plane certificates are managed by the system and rotated automatically. In the rare case that your control plane certificates have expired, see Recovering from expired control plane certificates .
apiVersion: v1 kind: ConfigMap metadata: name: user-ca-bundle namespace: openshift-config data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- Custom CA certificate bundle. -----END CERTIFICATE----- cat install-config.yaml proxy: httpProxy: http://<username:password@proxy.example.com:123/> httpsProxy: http://<username:password@proxy.example.com:123/> noProxy: <123.example.com,10.88.0.0/16> additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_HTTPS_PROXY_TRUSTED_CA_CERT> -----END CERTIFICATE----- apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 50-examplecorp-ca-cert spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= mode: 0644 overwrite: true path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt oc annotate -n openshift-kube-apiserver-operator secret kube-apiserver-to-kubelet-signer auth.openshift.io/certificate-not-after- oc get secret -n openshift-etcd etcd-signer -oyaml > signer_backup_secret.yaml oc delete secret -n openshift-etcd etcd-signer oc wait --for=condition=Progressing=False --timeout=15m clusteroperator/etcd oc delete configmap -n openshift-etcd etcd-ca-bundle oc adm wait-for-stable-cluster --minimum-stable-period 2m