이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 8. Responsive restarts and security certificates


MicroShift responds to system configuration changes and restarts after alterations are detected, including IP address changes, clock adjustments, and security certificate age.

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 clock changes is a time change of greater than 10 seconds in either direction. Smaller drifts on regular time adjustments performed by the Network Time Protocol (NTP) service do not cause 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
Have a certificate validity of one year. Most server or leaf certificates are short-lived.
Long-lived certificates
Have a certificate validity of 10 years. An example of a long-lived certificate is the client certificate for system:admin user authentication, or the certificate of the signer of the kube-apiserver external serving certificate.

MicroShift restarts automatically in certain cases, 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. This rotation can be an automatic process.

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), then all of the signed certificates rotate. If you created any custom CAs, ensure that the CAs manually rotate.

8.3.1. Short-term certificates 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 lifetimes:

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 certificates 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 lifetimes:

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat