Close kestrel https connections using old certificate versions
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 290
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Is your feature request related to a problem? Please describe the problem.
My team is using ServerCertificateSelector to provide the latest version of the ssl certificate when establishing connections. Upon a new version of the certificate being available on the machine and providing it to new connections we would like phase out connections that are using the old certificate. Doing this would allow us to quickly stop usage of the old certificate in case of a leak. I believe that connections would automatically close if idle but our scenario has continuous usage and our security teams logs suggest that one of these connections with the old certificate was alive for two months.
### Describe the solution you'd like
In order of preference we would love a solution like the following. The second and third would only allow closing when the existing connections are used which could be a significant amount of time but would prevent continued use on that connection, unless there is a way to enumerate the connections somehow to close those using the old certificate.
- The ability to set a max lifetime for a connection so that we have some upper bound for how long the old certificate will be used before.
- The ability to see which certificate was used for the connection via HttpContext.Connection
- The ability to set metadata on HttpContext.Connection so we could annotate the thumbprint used for the connection.
### Additional context
I understand this is an odd ask and will likely have very little usage. Any workarounds you could propose would be greatly appreciated.
One approach I was thinking about was if a tracking of the thumprint could be added to ConnectionContext.Features during the ServerCertificateSelector and then later fetched from the HttpContext.Features in a middleware but I am not sure if the same features will carry over. I'll perform a test for this, even if it works my understanding is that there may be connections that are kept-alive that are not receiving requests that could at any time become active again.
Contributor guide
Assessment
This issue has not been assessed yet.