Skip to content

Akka.Remote / Akka.IO: certificate rotation handling #7663

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Aaronontheweb opened this issue May 19, 2025 · 1 comment
Open

Akka.Remote / Akka.IO: certificate rotation handling #7663

Aaronontheweb opened this issue May 19, 2025 · 1 comment

Comments

@Aaronontheweb
Copy link
Member

Is your feature request related to a problem? Please describe.

We've had some requests for supporting certificate rotation handling inside Akka.Remote - and, well, to put it more aptly: we need to be able to handle multiple certificates with overlapping expiration dates so they can be safely rotated in production without downtime.

It looks to me like the .NET base classes for certificate validation should be able to support this:

Which means that this is mostly a "how do we expose this configuration to end-users and select the correct certificate?" exercise rather than a "is this even theoretically possible" exercise.

Describe the solution you'd like

After working on #7637 and doing some low-level TCP bits there, I think there are two ways of going about this:

  1. Write a general purpose TlsConfigurationSetup that either DotNetty, Akka.IO.Tcp, or our new Quic-based transport can select certificates from. Basically the idea is that we're going to expose the certificate selection configuration in an unopinionated way and then just consume it from inside the appropriate areas in Akka.NET - rather than have a bespoke setup for each type.
  2. This will probably replace the akka.remote.dot-netty.tcp.ssl configuration settings block when it's used.

Describe alternatives you've considered

We could try making this all doable with HOCON - passing in a certificate list or whatever. I'd be open to that if it's easier for end-users. We don't want to make users have to reason about ALL of the certificate selection details themselves if it can be helped.

@Aaronontheweb
Copy link
Member Author

I'm open to backporting this to v1.5 too btw - but I wanted it on the list as a v1.6-facing item primarily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant