Skip to content
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

Enabling TLS encryption on existing nodes #1705

Closed
calvn opened this issue Feb 9, 2016 · 2 comments
Closed

Enabling TLS encryption on existing nodes #1705

calvn opened this issue Feb 9, 2016 · 2 comments
Assignees
Labels
type/enhancement Proposed improvement or new feature

Comments

@calvn
Copy link
Contributor

calvn commented Feb 9, 2016

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!

@slackpad slackpad added the type/enhancement Proposed improvement or new feature label Feb 17, 2016
@slackpad
Copy link
Contributor

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.

@phlantin
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement Proposed improvement or new feature
Projects
None yet
Development

No branches or pull requests

4 participants