allow the clients of acceptor to specify their own tls.Config#667
Merged
ackleymi merged 4 commits intoSep 4, 2024
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLS certs go stale / expire overtime.
When they do, they need to be renewed.
Originally, when a server (acceptor) starts up, it configures its tls.Config to use for tls connections.
When this tls.Config uses / is set up with
Certificates []Certificate, then the cert will be stored / remain in memory, and will be static in nature. Any renewal on the disk would not affect that Certificates slice. The only way to effectuate the new certs is to reboot the server.This reboot may be undesirable / unnecessary, if the server would be able to load the server cert on demand.
Golang solves this issue, by allowing the tls.Config to load the server cert by a user specified function (
GetCertificate).This PR would allow the developer to specify a tls.Config of their choice, and in turn would allow them to be fully in control of the tls.Config of the acceptor (including the specification of such
GetCertificatefunction to avoid downtime in case of cert renewal)