dotnet / dotnet/aspnetcore

Close kestrel https connections using old certificate versions

Open
#60,380 4 comments 0 reactions 0 assignees View on GitHub
area-networking
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.