Consul: TLS verify_outgoing & server_name conflict: verifies peer using own name

[Millnert]

Having a separate IPA PKI setup with host/machine certificates is incompatible with the (futile?) way consul verifies TLS certificates.

The setting verify_outgoing requires verify_incoming, and verify_outgoing attempts to verify the configured 'server_name' setting on a server, when speaking with another server.

This is a very strange model, verifying that the name of the server you're connecting to matches your own name.

The related code appears to be in the tlsutil.Wrapper, i.e. https://github.com/hashicorp/consul/blob/master/tlsutil/config.go#L60 , and what that is used for.

This may be related to issue #362.
I see in that issue that there's a consideration due to the way information gets gossiped around. But it could be quite useful to allow Consul to rely on a separate PKI / TLS infrastructure (and DNS) infrastructure.

[slackpad]

Hi @Millnert,

Normally, Consul only verifies that a certificate is signed by a configured CA, it doesn't look at the hostnames. The config you cited is used by this feature - https://www.consul.io/docs/agent/options.html#verify_server_hostname. If verify_server_hostname is turned on, then Consul will also verify the hostname is server.<datacenter>.<domain>. This lets you create a special certificate just for servers to keep random clients with valid certificates from acting as a server.

I tagged this as docs because I think we can enhance the documentation about this. Does this make sense?

/cc @sean-

[clinta]

Thanks, this issue helped clarify what was unclear in the docs. This seems to me to be an odd way to controll whether a member has server or client access though.

x509 already has extended attributes to indiciate whether a certificate is valid for Server Authentication, Client Authentication or both. Only allowing servers to join if their certificate is valid for Server Authentication would be a more standard approach.

[i0rek]

We discussed Server Authentication vs Client Authentication internally and came to the conclusion that it is not applicable for consul. Every agent acts as a server when it provides its API, and as a client when it requests data from the leader, backed by the same certificate. This is why we cannot restrict client certificates to Client Authentication.

[i0rek]

I am going to close this issue now, but would be happy to reopen if there is something I missed.

[fhossain]

@i0rek in all other systems we use two sets of certificates. One for client and one for server. In cases where a server also acts as a client it gets two certificates. Using peer certificates (client and server combined) breaks this model and has to be special cased. If Consul server worked with two sets of certificates that would address @clinta's suggestion and would be a cleaner solution for a lot of users.