Proposal Details
Following Apple's proposal, the maximum certificate validity period is set to be reduced to 47 days (https://cabforum.org/working-groups/server/baseline-requirements/requirements). Let's encrypted even started to provide 7 days certificate
As a result, certificate hot reloading is becoming an increasingly critical feature.
While the current tls.Config supports hot reloading via GetCertificate, I find myself copy-pasting the same boilerplate code (reading files and starting a goroutine for updates and some atomic ops) in almost every project that uses certificates.
We could provide a helper function(to golang.org/x/) that takes the certificate file path as input and returns a function matching the func(*ClientHelloInfo) (*Certificate, error) signature. This would allow it to be used directly in tls.Config while managing the hot reloading logic internally.
Proposal Details
Following Apple's proposal, the maximum certificate validity period is set to be reduced to 47 days (https://cabforum.org/working-groups/server/baseline-requirements/requirements). Let's encrypted even started to provide 7 days certificate
As a result, certificate hot reloading is becoming an increasingly critical feature.
While the current tls.Config supports hot reloading via GetCertificate, I find myself copy-pasting the same boilerplate code (reading files and starting a goroutine for updates and some atomic ops) in almost every project that uses certificates.
We could provide a helper function(to golang.org/x/) that takes the certificate file path as input and returns a function matching the
func(*ClientHelloInfo) (*Certificate, error)signature. This would allow it to be used directly in tls.Config while managing the hot reloading logic internally.