If we only want to encrypt the traffic and do not care about the root cert's validity then there's no need to create an issue for ejabberd, or to wait for a verify-ca feature.
I think the PR is good to go, since right now Mastodon and ejabberd connect to PostgreSQL using localhost, so the ejabberd cookbook will only need to be updated to create a cluster with the new server
Good implementations of PostgreSQL clients give you the option of verifying the cert was generated with the root cert, verify-ca. For example Gitea calls it verify-ca like the PostgreSQL documentation: https://docs.gitea.io/en-us/config-cheat-sheet/#database-database
Since we decided to use IPs, we wouldn't want to check the hostname (or use it), but ejabberd has no option for verify-ca, so ejabberd wouldn't verify anything
See https://www.postgresql.org/docs/12/libpq-ssl.html#LIBPQ-SSL-PROTECTION for the implication of every option
In ejabberd you pass it a path to the CA root certs (https://docs.ejabberd.im/admin/configuration/toplevel/#sql-ssl-cafile). This part works, it fails verifying the hostname
I have pushed changes to my PR (#163) to switch over to a self-signed certificate. In VMs I got it to work, including with psql's verify-ca option.
In my experiments I could not get ejabberd's sql_ssl_cafile and sql_ssl_verify to ever work. At first I thought it was because my cert was a wildcard cert, but I got the same issue with a certicate generated for an example domain (primary.kosmos.org with an /etc/hosts entry) too.
I am always getting this error in ejabberd, so we will do have to do without cert validation, or create an issue: TLS client: In state certify at ssl_handshake.erl:1372 generated CLIENT ALERT: Fatal - Handshake Failure - {bad_cert,hostname_check_failed}.
I also noticed that ejabberd does not support connecting to PostgreSQL servers with only TLS v1.3 enabled, so I have configured it to enable a minimum of v1.2 (
additional_config[:ssl_min_protocol_version] = "TLSv1.2" |
Thanks, I've pushed a fix for the typo
They're Chef custom resources (https://docs.chef.io/custom_resources/), the concept that replaces LWRP (https://chef.readthedocs.io/en/latest/lwrps_custom.html)
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.
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)
re: TLS, it's still useful between clients and servers even with firewall rules and access rules
I ran into a Chef bug that appears to be caused by the implementation of custom resources. Notifications are broken, so adding an access rule using the postgresql_access does not reload the service: https://github.com/sous-chefs/postgresql/issues/648
The custom resource I wrote was really useful since so much code is identical between a primary and a replica, but I might have to rewrite it another way (move the access rules to the recipe, for example). With this bug reloading the PostgreSQL service manually is needed after adding a new rule
I created a repo to reproduce the issue, a maintainer will take a look at it
This took more work than I originally thought to get it right, but I'm getting satisfied with the Chef resource I wrote to set up a PostgreSQL primary or replica, with a TLS cert provided by Let's Encrypt.
Now I'm going to perform the PostgreSQL upgrade in a VM and make sure everything goes smoothly