# Vault TLS cluster setup **URL:** \ **Category:** Vault\ **Tags:** vault\ **Created:** [May 24, 2021, 6:19am UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682 "2021-05-24T06:19:03Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![surajthakur](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/surajthakur/32/4389_2.png) [@surajthakur](https://discuss.hashicorp.com/u/surajthakur)\ **Post date:** [May 24, 2021, 6:19am UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682/1 "2021-05-24T06:19:03Z")
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. ```auto 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 ```auto 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](https://vault.abc.com) will be resolved by the load balancer and send requests to active vault server ---
**Author:** ![mikegreen](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/mikegreen/32/3160_2.png) [@mikegreen](https://discuss.hashicorp.com/u/mikegreen)\ **Post date:** [May 24, 2021, 5:18pm UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682/2 "2021-05-24T17:18:26Z")
> [@surajthakur](#): > > wildcard certificate does not identify the IP of the vault nodes 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? > [@surajthakur](#): > > We do not have any internal DNS server to resolve locally 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: > **[High Availability | Vault | HashiCorp Developer](https://developer.hashicorp.com/vault/docs/concepts/ha)** > > Vault can be highly available, allowing you to run multiple Vaults to protect against outages. ---
**Author:** ![surajthakur](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/surajthakur/32/4389_2.png) [@surajthakur](https://discuss.hashicorp.com/u/surajthakur)\ **Post date:** [May 24, 2021, 11:46pm UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682/3 "2021-05-24T23:46:10Z")
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](http://debian1-vault.abc.com) cannot resolve the IP’s of [debian2-vault.abc.com](http://debian2-vault.abc.com) or [debian3-vault.abc.com](http://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 ? ---
**Author:** ![mikegreen](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/mikegreen/32/3160_2.png) [@mikegreen](https://discuss.hashicorp.com/u/mikegreen)\ **Post date:** [May 25, 2021, 5:04pm UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682/4 "2021-05-25T17:04:44Z")
> [@surajthakur](#): > > because they are not mapped on public DNS and we do not have any private DNS server IMO this is an anti-pattern. Are you saying you don’t use hostnames for servers within your environment, and only IP addresses? ---
**Author:** ![surajthakur](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/surajthakur/32/4389_2.png) [@surajthakur](https://discuss.hashicorp.com/u/surajthakur)\ **Post date:** [May 27, 2021, 6:18am UTC](https://discuss.hashicorp.com/t/vault-tls-cluster-setup/24682/5 "2021-05-27T06:18:15Z")
> [@mikegreen](#): > > 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](http://debian-1.abc.com), [debian-2.abc.com](http://debian-2.abc.com), [debian-3.abc.com](http://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](http://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.