You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.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.
The text was updated successfully, but these errors were encountered: