Alert earlier for expiring certificates

[manuelbuil]

Is your feature request related to a problem? Please describe.

K3s creates leaf certificates expire after 365 days. When the certificate is within 90 days to expire, K3s creates an event that warns about this expiration being soon. Moreover, within those 90 days, a restart of the node will automatically rotate the certificates.

I would like to increase that "window" of automatic-rotation and warning from 90 to 120 days. This would make the rotation of certificates more likely to happen and that would help users that upgrade every quarter.

For example, the Third Quarter (Q3): July 1 - September 30 has 92 days. Imagine the certificates expire on September 29th and the user upgrades and restarts on June 30th and plans the next upgrade and restart on September 30th. On July the 2nd, the "window" would start, i.e. the user will get the expiration warning and a restart would rotate the certificates but imagine the user does not do anything with this cluster until the next upgrade "date". By the time the user does the upgrade (September 30th), the certificates will have expired and the cluster will not work correctly.

Describe the solution you'd like

Increase the automatic-certificate window to 120 days or even make it configurable, within an acceptable range, e.g. 90 to 365 days. The latter (365 days) would mean that the certificate gets rotated in every restart, which might be a good solution for certain people, although it should be checked if that scales

Describe alternatives you've considered

Additional context

[dereknola]

We have actively fought against giving users a foot-shotgun and attempting to set 10 years on the cert expiration. Moving to a longer, but still limited window of 120 is the better option.

[brandond]

This is not an objection - but I should note that this is the opposite of where the industry as a whole is going. CAs are working to reduce the max validity of leaf certificates to 47 days by March 2029:

https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/bvWh5RN6tYI

• Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years
  • Eventual reduction of maximum validity period from 398 days to 47 days
• These reductions are proposed to occur starting in March 2026 and concluding in March 2029

While increasing the default duration may be a small quality of life improvement for our users, a more meaningful improvement would be using certs with shorter validity periods that are automatically renewed without requiring a restart.

[manuelbuil]

Hold on, there might be a confusion about this request, probably because of the description I wrote or the title, sorry about that. Let me try to explain and please correct me if I am wrong.

K3s currently sets the expiration date to 365 days (1 year) after the certificate is created. When the certificate is within 90 days of expiration, i.e. 275 days after its creation, K3s warns the user and a restart of the node will automatically rotate the certificate. My request is to increase that "window" of automatic certificate rotation to, e.g. 120 days or make it configurable. That would make restarts more likely to trigger a certificate rotation, thus making it less likely for certificates to expire.

However, I am not suggesting to extend the expiration date to more than a year or make it configurable. Therefore, I don't think this change would reduce the security of the system, if anything, it would slightly increase it because it is more likely that K3s rotates certificates often.

Let me rewrite the description a bit to make it clearer

[manuelbuil]

I changed the title to avoid confusion. Now I think the intent is clearer

[Tejeev]

@brandond this is another issue asking for more frequent cert rotation. I'll add it to the Jiras

[cwayne18]

@Tejeev this is our internal issue, it's not another customer asking it's a tracking issue on our end. Currently slated for May releases

[Tejeev]

@cwayne18 ah, cheers for the clarification. It wasn't in the Jira I was tracking as the main, so didn't realize. It should have been obvious, but I didn't see that that was our Manuel who opened it :P

[Tejeev]

except that alerting earlier is a very different path from the one most folks are requesting, and arguably less secure. What was our reasoning for this workaround? Customers will be asking when they see the casename change.