I'm removing that line, this will be done as part of the Mastodon, ejabberd, gitea cookbooks. They wouldn't use a different port, but clients still need access for the specific database, user and IP (https://www.postgresql.org/docs/12/auth-pg-hba-conf.html)
I forgot to remove that part from the README, as we said in #160 that we don't care about verifying the root cert. It would be done in the cookbooks for software that connects to PostgreSQL (together with creating databases) and not in this cookbook
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