Questo contenuto non è disponibile nella lingua selezionata.

Chapter 8. Responsive restarts and security certificates


MicroShift automatically restarts when system configuration changes are detected. These changes include IP address updates, clock adjustments, and security certificate expiration.

8.1. IP address changes or clock adjustments

MicroShift depends on device IP addresses and system-wide clock settings to remain consistent during its runtime. However, these settings might occasionally change on edge devices.

For example, DHCP or Network Time Protocol (NTP) updates can change times. When these changes occur, some MicroShift components might stop functioning properly. To mitigate this situation, MicroShift monitors the IP address and system time and restarts if either setting changes.

The threshold for a clock-driven restart is a time change of greater than 10 seconds in either direction. Small drifts during regular NTP service adjustments do not trigger a restart.

8.2. Security certificate lifetime

MicroShift certificates are digital certificates that secure communication with communication protocols such as HTTPS. They fall into two basic categories:

Short-lived certificates
Valid for one year. Most server or leaf certificates are short-lived.
Long-lived certificates
Valid for 10 years. For example, the client certificate for system:admin user authentication, or the kube-apiserver external serving certificate signer.

MicroShift restarts automatically depending on certificate age.

8.3. Certificate rotation

Certificates that are expired or close to their expiration dates must be rotated to ensure continued MicroShift operation. Certificate rotation can occur automatically.

When MicroShift restarts for any reason, certificates that are close to expiring are rotated. A certificate that expires soon, or has already expired, can also cause an automatic MicroShift restart to perform a rotation.

Important

If the rotated certificate is a MicroShift certificate authority (CA), all signed certificates are also rotated. If you created custom CAs, you must rotate them manually.

8.3.1. Short-term-certificate rotation

Short-term certificates that are expired or close to their expiration dates must be rotated to ensure continued MicroShift operation.

The following situations describe MicroShift actions during short-term-certificate lifetime:

No rotation
When a short-term certificate is up to 5 months old, no rotation occurs.
Rotation at restart
When a short-term certificate is 5 to 8 months old, it is rotated when MicroShift starts or restarts.
Automatic restart for rotation
When a short-term certificate is more than 8 months old, MicroShift can automatically restart to rotate and apply a new certificate.

8.3.2. Long-term-certificate rotation

Long-term certificates that are expired or close to their expiration dates must be rotated to ensure continued MicroShift operation.

The following situations describe MicroShift actions during long-term certificate lifetime:

No rotation
When a long-term certificate is up to 8.5 years old, no rotation occurs.
Rotation at restart
When a long-term certificate is 8.5 to 9 years old, it is rotated when MicroShift starts or restarts.
Automatic restart for rotation
When a long-term certificate is more than 9 years old, MicroShift might automatically restart so that it can rotate and apply a new certificate.
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni sulla documentazione di Red Hat

Legal Notice

Theme

© 2026 Red Hat
Torna in cima