Left a couple of comments/questions.
I don't see where that's done in this PR?
What does this mean? Why would they use a different port to connect to Postgres?
I'm not sure I follow. The point of verifying a hostname, is that it can change. That's the problem with DNS.
Thus, the question is still open: why would we have to verify the cert on the client in this scenario? It is a simple local config. And it is only there to encrypt the connection, so that someone outside of our machines cannot record unencrypted traffic, when it's flowing through a public network. Nothing else.
So the options for this use case are:
- Use a private network
- Encrypt the connection on a public network
The easiest way to achieve number 2 is with simple shared certificates that we ourselves configure on the machines.
... also, aside from not needing a hostname, why would we have to verify the cert on every connection? Someone who could replace the IP could also replace the local cert used.
it fails verifying the hostname
What hostname? Why would we use hostnames?
Sounds to me like this is all much more complicated than just setting up a private network to be honest.
But in any case, does that mean ejabberd comes with its own CA list/store, or why would it ignore a Kosmos CA cert from the system store (like when you just use update-ca-certificates e.g.)?
... also not mentioning short expiration dates and frequent renewals, of course. None of that is necessary with a connection between private servers, where the only point is to encrypt the connection between the particular, internal machines.
TLS with Let's Encrypt is easier to set up than a self signed cert on all machines. In my experience generating self-signed certs in a pain in the ass.
How is LE easier than running literally a single command on any POSIX system with OpenSSL installed? Storing it in a data bag is as easy.
If the primary PostgreSQL server is for example andromeda.kosmos.org with TLS, changing it to another server in the client configs is the same amount of work as changing an IP (changing the FQDN)
That completely disregards my criticism of using DNS here. And if you change the entire hostname, then it's obviously more work on both ends than simply changing the IP only.
There is an open PR now, and the question why we need DNS and LE is still left unanswered by it. I think a normal custom cert, based on a Kosmos root cert that all machines can use, would have been much easier to begin with, but also that it makes more sense overall.
With DNS, we have to change hostnames instead of IPs, which requires waiting for the cache to update. And LE isn't required at all when there are no public clients using DNS. A simple X509 cert, based on a shared Kosmos root CA, would suffice.
I glanced over everything and added a few comments to the mentioned README.
What's "custom" about these servers? If "custom" merely means that it's going to be configured for our use case, then isn't that the case for literally every other server, too?
The replica also needs to have "primary" as role?
Which rules are needed? How are they declared? I believe this README would not answer these questions for someone trying to use it.
I didn't ask why we need TLS, but why we would need DNS and Let's Encrypt. It seems like you're proposing to use both in addition to TLS.
Why would we need Let's Encrypt tho? We don't want any public clients to access it.
Just found out it's possible to set up normal XMPP auth for Jitsi Meet room creation after all: