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 there a way to enable TLS encryption as outlined in https://www.consul.io/docs/agent/encryption.html without causing downtime on nodes, more specifically on the clients? Enabling encryption in outgoing connection is trivial since it only involves re-configuring the server, and encrypted traffic does not affect client nodes. However, I can't seem to find a way to encrypt incoming connections without causing downtime on the clients during the transition.
As soon as the verify_incoming flag is set to true, the server freaks out on the client (and the client can't make any RPC calls) until the client as the proper configuration set. Hoping to get around this, I've also tried the reverse and set the flag on the client first, but it still has blocked RPC calls right from the moment I set the value to true.
Perhaps if Consul supported dual operation mode to handle both encrypted and unencrypted traffic, it could make such transition easier. Any suggestion to address this would be much appreciated!
The text was updated successfully, but these errors were encountered:
Hi @cleung2010 unfortunately, there's currently no zero-downtime way to cutover to TLS. We've had a few other folks run into this so we will take a look into how hard this would be to support.
Has the option of offering secure rpc via a different port been considered? This will allow both secure and non-secure connections, and a migration path for clients.
Is there a way to enable TLS encryption as outlined in https://www.consul.io/docs/agent/encryption.html without causing downtime on nodes, more specifically on the clients? Enabling encryption in outgoing connection is trivial since it only involves re-configuring the server, and encrypted traffic does not affect client nodes. However, I can't seem to find a way to encrypt incoming connections without causing downtime on the clients during the transition.
As soon as the
verify_incoming
flag is set to true, the server freaks out on the client (and the client can't make any RPC calls) until the client as the proper configuration set. Hoping to get around this, I've also tried the reverse and set the flag on the client first, but it still has blocked RPC calls right from the moment I set the value to true.Perhaps if Consul supported dual operation mode to handle both encrypted and unencrypted traffic, it could make such transition easier. Any suggestion to address this would be much appreciated!
The text was updated successfully, but these errors were encountered: