Hi Community,
I have a query regarding TLS setup in vault cluster. We have decided to use integrated raft storage as backend.
I have a wildcard certificate *.abc.com and I plan to use that for TLS cert in listener section for tls_cert_file. I get my first node up, but when i start the second node up I get TLS errors cannot validate certificate for 192.168.1.20 because it doesn't contain any IP SANs
which i understand that my wildcard certificate does not identify the IP of the vault nodes.
So I got it working by making my hostnames as below and resolved them internally in /etc/hosts on all three nodes.
192.168.1.20 debian1-vault.abc.com
192.168.1.21 debian2-vault.abc.com
192.168.1.22 debian3-vault.abc.com
We do not have any internal DNS server to resolve locally as we never had requirement.
Is this good approach to do ? What could be right way to get this working.
This is my vault.conf
storage "raft" {
path = "/opt/raft"
node_id = "raft_node_2"
}
listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "192.168.1.21:8201"
tls_cert_file = "/etc/vault.d/certs/vault_cert.crt"
tls_key_file = "/etc/vault.d/certs/vault_cert.key"
}
ui=true
disable_mlock = false
api_addr = "https://vault.abc.com:8200"
cluster_addr = "https://192.168.1.21:8201"
The domain: https://vault.abc.com will be resolved by the load balancer and send requests to active vault server
1 Like
Correct. WIth your config, you should have the IP address in the certificate IP SAN.
You can set the cluster_address to the hostname, and then it will use DNS to resolve. But seems like you don’t have DNS here?
Vault servers without a DNS resolver? That sounds non-standard, but might not be 
Read up here and make your decision - I’d recommending adding the IP addresses to the cert:
Thanks @mikegreen . Using hostname would work I think, which means server hostname should be debian1-vault.abc.com, debian2-vault.abc.com, debian3-vault.abc.com whereas right now i had hostnames as debian1-vault.example.com, debian2-vault.example.com, debian3-vault.example.com. Thats makes sense that the server hostnames should in the domain the wildcard cert CN name is, if we don’t want to add IP in the cert(which i am not sure if it is possible).
What I meant with: We do not have any internal DNS server to resolve locally is debian1-vault.abc.com cannot resolve the IP’s of debian2-vault.abc.com or debian3-vault.abc.com using the domain name, because they are not mapped on public DNS and we do not have any private DNS server.
So do you say that not having a private DNS server is non-standard ?
So in this case, should we resolve the cluster IP’s to their hostnames in /etc/hosts on each server ? or What else could be a better approach ?
IMO this is an anti-pattern. Are you saying you don’t use hostnames for servers within your environment, and only IP addresses?
No, The instances have hostnames which are currently like debian-1, debian-2, debian-3
which I understand now that hostnames should be debian-1.abc.com, debian-2.abc.com, debian-3.abc.com, to fix the IP san certificate issue.
But what I meant was if from instance debian-1, you try to ping debian-2.abc.com or debian-2 , instance debian-1 wont resolve it, it wont know the IP, because the hostnames are not mapped to route53, and neither they talk to any internal DNS server, until we locally map them in /etc/hosts
We do have consul, which we use for service discovery, for different projects, but we wanted to keep vault isolated from other projects and since now vault provided integrated storage, we didnt wanted to bring in consul ad storage backend.