Problems with Consul TLS

576 views
Skip to first unread message

Francisco Javier Romero Mendiola

unread,
May 25, 2016, 12:04:02 PM5/25/16
to Vault
I am setting up TLS on Consul and Vault and this is my scenario.

Vault Server + Consult Agent (client) on the same machine.
Consul Agent (server) on other machine.

Vault file:

listener "tcp" {
   address = "0.0.0.0:8200"
   tls_cert_file = "/etc/vault/certs/vault.crt"
   tls_key_file = "/etc/vault/certs/private/vault.key"
}

backend "consul" {
   address = "127.0.0.1:8443"
   path = "vault"
   scheme = "https"
   token = "SECRET"
   tls_ca_file = "/etc/consul/certs/consul_ca.crt"
   tls_cert_file = "/etc/consul/certs/consul.crt"
   tls_key_file = "/etc/consul/certs/private/consul.key"
}

Consul file:

{
   ...
  "verify_incoming": true,
  "verify_outgoing": true,
  "key_file": "/etc/consul/certs/private/consul.key",
  "cert_file": "/etc/consul/certs/consul.crt",
  "ca_file": "/etc/consul/certs/consul_ca.crt"
}

I have problems with CN certificate because the address for every Consul agent (client) is "127.0.0.1" and I think It is not secure create certificates with "CN=127.0.0.1".

I am wondering what happens if I disable "verify_incoming" parameter and I keep "verify outgoing=true":

Vault send data -No TLS-> Consul Agent (client) -TLS or no TLS?-> Consul Agent (Server)

Any help is appreciated.

Jeff Mitchell

unread,
May 26, 2016, 9:59:58 AM5/26/16
to vault...@googlegroups.com
Hi Francisco,

You could use the tls_skip_verify parameter in the consul backend
block to prevent Vault from actually checking the certificate's
validity.

You could also re-create the certificate with 127.0.0.1 added as an IP
Subject Alternate Name, although that has the same drawbacks as simply
making that the CN.

Another idea would be to put in a local DNS entry (e.g. in /etc/hosts)
for whatever CN is on the certificate mapping to 127.0.0.1, then set
that CN as the address. That way when the lookup is performed it'll
connect to the local daemon but it will look for the CN.

A final idea would be to simply not use TLS between Vault and the
local Consul agent. Outside of the seal configuration (which tampering
with would simply make Vault not work), everything in Vault is
encrypted before it's sent down the wire to the storage backend.
Having TLS to the local agent is nice, but you won't defeat Vault's
security by not having it.

Best,
Jeff
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/dad22a03-e420-40c8-961f-ef50f1a157c7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Francisco Javier Romero Mendiola

unread,
May 26, 2016, 10:23:12 AM5/26/16
to Vault
Thanks for you reply Jeff.

In your third case with "verify_outgoing" parameter set, does Consul Agent (client) send data to Consul Agent (server) via TLS or Consul Agent (client) response to Vault with IP Consul Leader and Vault sends the data directly?

On the other hand, I am not sure about CN certificates. Server consul hostnames are Consul[1-3] , what should be the CN (or SANs) for my certificates?

Francisco.

Jeff Mitchell

unread,
May 26, 2016, 6:26:03 PM5/26/16
to vault...@googlegroups.com
On Thu, May 26, 2016 at 10:23 AM, Francisco Javier Romero Mendiola
<fjro...@paradigmadigital.com> wrote:
> Thanks for you reply Jeff.
>
> In your third case with "verify_outgoing" parameter set, does Consul Agent
> (client) send data to Consul Agent (server) via TLS or Consul Agent (client)
> response to Vault with IP Consul Leader and Vault sends the data directly?
>
> On the other hand, I am not sure about CN certificates. Server consul
> hostnames are Consul[1-3] , what should be the CN (or SANs) for my
> certificates?

Hi Francisco,

Consul agents forward requests to the servers; they do not redirect.

As for certificates, it's really up to you. If you don't want to put
127.0.0.1 in your IP SANs, you could put any CN that you're happy
putting in /etc/hosts as a local host name.

Best,
Jeff

Francisco Javier Romero Mendiola

unread,
May 27, 2016, 4:13:50 AM5/27/16
to Vault
Thanks again Jeff.

One last question about certificates, If I set "verify_outgoing" and "verify_server_hostname" parameters I guess that CN and SANs parameters should be suitable with Consul Agents hostnames. What does it should be?

consul[1-3] or consul[1-3].consul.service.consul

Francisco

Francisco Javier Romero Mendiola

unread,
May 27, 2016, 6:52:52 AM5/27/16
to Vault
I have making some tests:

    2016/05/27 12:43:58 [ERR] raft: Failed to make RequestVote RPC to 10.200.11.109:8300: x509: certificate is valid for consul, not  server.MYDATACENTERNAME.consul
sul
   
2016/05/27 12:43:58 [ERR] raft: Failed to make RequestVote RPC to 10.200.11.110:8300: x509: certificate is valid for consul1, consul2, consul3, no
t server
.MYDATACENTERNAME.consul


server.domain.consul is the CN for raft protocol?

I think It should be "server_name.domain.consul" not "server" for everyone.

Jeff Mitchell

unread,
May 27, 2016, 7:39:52 AM5/27/16
to vault...@googlegroups.com

Hi Francisco,

I honestly don't know enough about Consul's certificate handling to answer that correctly. This might be a good question to pose on the Consul mailing list. From a Vault perspective of you can talk to these local agent (which is the recommended method), my Consul work is done :-D Agent to server communications aren't my specialty...

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

Francisco Javier Romero Mendiola

unread,
May 27, 2016, 7:45:41 AM5/27/16
to Vault
You are right Jeff :)

I will send my questions to Consul mailing list.

Thank you!
Reply all
Reply to author
Forward
0 new messages