diff --git a/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst b/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst index b1e2588571..d19fc92efb 100644 --- a/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst +++ b/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst @@ -60,6 +60,28 @@ which explains using and implementing GraphStages in more practical terms than t .. _Mastering GraphStages, part I: http://blog.akka.io/streams/2016/07/30/mastering-graph-stage-part-1 +Remote +====== + +Mutual TLS authentication now required by default for netty-based SSL transport +------------------------------------------------------------------------------- + +Mutual TLS authentication is now required by default for the netty-based SSL transport. + +Nodes that are configured with this setting to ``on`` might not be able to receive messages from nodes that run on older +versions of akka-remote. This is because in versions of Akka < 2.4.12 the active side of the remoting +connection will not send over certificates even if asked to. + +It is still possible to make a rolling upgrade from a version < 2.4.12 by doing the upgrade stepwise: + * first, upgrade Akka to the latest version but keep ``akka.remote.netty.ssl.require-mutual-authentication`` at ``off`` + and do a first rolling upgrade + * second, turn the setting to ``on`` and do another rolling upgrade + +For more information see the documentation for the ``akka.remote.netty.ssl.require-mutual-authentication` configuration setting +in akka-remote's `reference.conf`_. + +.. _reference.conf: https://github.com/akka/akka/blob/master/akka-remote/src/main/resources/reference.conf + Cluster ======= diff --git a/akka-remote/src/main/resources/reference.conf b/akka-remote/src/main/resources/reference.conf index d62f59cb2d..451e791403 100644 --- a/akka-remote/src/main/resources/reference.conf +++ b/akka-remote/src/main/resources/reference.conf @@ -637,21 +637,20 @@ akka { # checks if the passive side (TLS server side) sends over a trusted certificate. With the flag turned on, # the passive side will also request and verify a certificate from the connecting peer. # - # To prevent man-in-the-middle attacks you should enable this setting. For compatibility reasons it is - # still set to 'off' per default. + # To prevent man-in-the-middle attacks this setting is enabled by default. # # Note: Nodes that are configured with this setting to 'on' might not be able to receive messages from nodes that - # run on older versions of akka-remote. This is because in older versions of Akka the active side of the remoting - # connection will not send over certificates. + # run on older versions of akka-remote. This is because in versions of Akka < 2.4.12 the active side of the remoting + # connection will not send over certificates even if asked. # - # However, starting from the version this setting was added, even with this setting "off", the active side - # (TLS client side) will use the given key-store to send over a certificate if asked. A rolling upgrades from - # older versions of Akka can therefore work like this: - # - upgrade all nodes to an Akka version supporting this flag, keeping it off - # - then switch the flag on and do again a rolling upgrade of all nodes + # However, starting with Akka 2.4.12, even with this setting "off", the active side (TLS client side) + # will use the given key-store to send over a certificate if asked. A rolling upgrade from versions of + # Akka < 2.4.12 can therefore work like this: + # - upgrade all nodes to an Akka version >= 2.4.12, in the best case the latest version, but keep this setting at "off" + # - then switch this flag to "on" and do again a rolling upgrade of all nodes # The first step ensures that all nodes will send over a certificate when asked to. The second # step will ensure that all nodes finally enforce the secure checking of client certificates. - require-mutual-authentication = off + require-mutual-authentication = on } }