We used to pre-generate the kube-proxy and k3s-controller certs on startup and send them to clients. This was one of the reasons that you had to rotate certs on servers first, then on agents - as the cert was actually only rotated when the server was restarted. We changed this so that it is generated on demand and never written to disk, essentially orphaning that file.
2e4e7cf#diff-57e07d197b4ab865cbfb7d7c625f85cf6eacf6b0a341c7fe87cb98bf85851912

Now only the key is pregenerated, and even this is only used for legacy clients, new clients send a CSR with a public key and that key is used to sign their cert. This is all part of the same change:

• Move supervisor API request handlers into dedicated package and add unit tests #11471

Allow clients to generate their own keys, instead of requiring them to use key generated by the server

• Improves overall security posture by no longer reusing private keys for agent certificates across multiple nodes in the cluster. Both agent and server contain backwards-compatibility code to allow interop with other version that do not support certificate signing requests when acquiring agent certs.
• After upgrading, existing nodes can be re-keyed to use unique keys by deleting their existing certs and keys from disk or running k3s certificate rotate, and restarting the node.
• This also removes the requirement to rotate certs on servers before agents, since they no longer reuse certs+keys pre-generated by the server. Agent certs will in fact be renewed (with the same key) on every startup. Rotation will work as it currently does, where the keys are removed to force creation of new keys and certs.

These files are now unused, but still show up in certificate checks. We should delete them on startup, since they are unused, do not get renewed, and will cause spurious certificate expiry alerts.

x-ref: rancher/rke2#8431 (reply in thread)