From #24254:

I wonder if there is any real use case for reloading the system cert pool.

One use case is long-running processes that now have to jump through hoops to update their view of the system cert pool (e.g. openshift/cloud-credential-operator#113). On Unix, the loading logic is expensive, traversing multiple directories. But for processes who know they can load certs from a single file, it would be nice to have a way to reload if the backing file had changed but not otherwise. For example, something like:

// NewCertPoolsFromFile parses a series of PEM encoded certificates from the file at the
// given path and records the Stat ModTime of the loaded file.  When the pool is used to
// verify a certificate, it has been more than a minute since the last Stat, and a fresh
// Stat gives a ModTime newer than the cached value, the file is reloaded before being
// used to perform the verification.
func NewCertPoolFromFile(path string) *CertPool

Obviously the "don't bother Stating again" time could be configurable if that seemed important. Or maybe checking the current time is about as expensive as running the Stat, so we should just call Stat on every contains. Or maybe there would be no auto-refresh in contains, but CertPool would become an interface:

type CertPool interface {
  BySubjectKeyID(key string) []*Certificate
  ByName(name string) []*Certificate
}

In which case there could be a from-file CertPool implementation with a Refresh method to trigger the Stat check and possible reload. Or something ;). But having something in the stdlib that could be dropped into tls.Config.RootCAs to get efficient reloads without the caller having to babysit the CertPool would be great. Thoughts?