Exception inside DotNetty TLS handler isn't propagated to Akka.Remote

[Arkatufus]

Version Information
Version of Akka.NET? v1.5 and dev
Which Akka.NET Modules? Akka.Remote

Describe the bug

• DotNetty TLS behavior
  • Handshake failures inside DotNetty.Handlers.Tls.TlsHandler don’t propagate via ExceptionCaught; instead they are emitted as a user event (TlsHandshakeCompletionEvent) and the channel is closed.
  • If no handler in the pipeline processes that event, upstream code only sees the channel close, not the handshake exception.
  • Source code: https://github.com/Azure/DotNetty/blob/00c23606cc8afb699ee17790c51a85c0abf6d296/src/DotNetty.Handlers/Tls/TlsHandler.cs#L657-L666
• Akka.Remote’s DotNetty pipeline
  • Server pipeline: SetServerPipeline() inserts TlsHandler first, then framing/writer, then TcpServerHandler (src/core/Akka.Remote/Transport/DotNetty/DotNettyTransport.cs).
  • Client pipeline is similar (SetClientPipeline()).
  • TcpHandlers (base for both server/client handlers) does not override UserEventTriggered, so it never observes TlsHandshakeCompletionEvent.
  • When TLS handshake fails and the channel closes, the only thing that fires in Akka.Remote is ChannelInactive which calls NotifyListener(new Disassociated(DisassociateInfo.Unknown)) (src/core/
    Akka.Remote/Transport/DotNetty/TcpTransport.cs, method ChannelInactive). That explains “disassociation” logs with no underlying cause.
  • TcpHandlers.ExceptionCaught would log at ERROR and disassociate, but because TLS handshake failures aren’t delivered via ExceptionCaught, this never runs for that scenario.
  • Result: server appeared to start “fine,” and the first inbound TLS handshake silently failed (from Akka.Remote’s perspective), resulting in a disassociation without an error.

To Reproduce

1. Import the certificate (with private key) into the machine store

• Open certlm.msc → Personal → Certificates → All Tasks → Import…
• Import the .pfx. Choose Local Computer store (Personal\My), not Current User.

2. Grant the app identity access to the private key

• Still in certlm.msc, right-click the cert → All Tasks → Manage Private Keys…
• Add the application user (e.g., DOMAIN\MyServiceUser or the IIS app pool identity) and give it Read permission.

This updates the ACL on the key file under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\… (for CSP) or the CNG keys store.

3. Run the app as that user

• For a Windows Service: set Log On As to the service account.
• For an IIS app: ensure the App Pool identity you granted permissions to is what runs the site / app.

[Aaronontheweb]

resolved via #7824