1

I enabled SSL on my PostgreSQL database and enforced it using pg_hba.conf with the following line:

hostssl all all 0.0.0.0/0 md5

From the PostgreSQL connection logs and network traffic captured via tcpdump, it seems that SSL connections are being made:

2024-10-20 10:12:16.140 UTC [63] LOG: connection authenticated: identity="user" method=md5 (/etc/postgresql/pg_hba.conf:136) 2024-10-20 10:12:16.140 UTC [63] LOG: connection authorized: user=user database=db SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)

However, as Dovecot and PostgreSQL are running on different machines and the certificate and its CA are not trusted in dovecot machine, I expected Dovecot, which connects to PostgreSQL to flag an issue with the self-signed certificate, but there are no complaints. This leads me to believe that the certificate is not being properly validated, making the connection vulnerable to attacks like MITM (Man-in-the-Middle).

Is there an extra configuration or step I'm missing to enforce certificate validation? How can I ensure that connections are secure, and the certificate is being properly validated?

Improve this question
5
  • What "validation" are you expecting for a self signed certificate? Also, have you attempted to establish an regular unencrypted connection? That should be denied if encryption is enforced. Commented Oct 20, 2024 at 21:03
  • Also: The system on which Dovecot is running may be a trusted CA for certificates generated on that physical machine. Is PostgreSQL running on the same machine as Dovecot? If you point Dovecot at a PostgreSQL server on a separate machine, does it complain then? Commented Oct 20, 2024 at 21:14
  • 1
    @GregAskew I'm expecting Dovecot to complain about the certificate being self-signed or untrusted by the system, which should trigger a warning or rejection unless I explicitly configure Dovecot to trust the certificate. After I enabled SSL on PostgreSQL, Dovecot automatically started making encrypted connections without any further changes on my part. My concern is that it accepted the self-signed certificate without raising any issues, which makes me question whether proper certificate validation is happening. Commented Oct 20, 2024 at 21:16
  • @tsc_chazz Dovecot and PostgreSQL are running on different machines. The certificate and its CA are not trusted in dovecot machine. Commented Oct 20, 2024 at 21:18
  • Until it is configured to enforce TLS, I would expect unencrypted connections to succeed. Commented Oct 20, 2024 at 21:41

1 Answer 1

Reset to default
1

This is client configuration issue, and the supported client library for PostgreSQL is called libpq, which Dovecot is using. The related manual page, libpq SSL Support (for the verison 17), states explicitely:

By default, PostgreSQL will not perform any verification of the server certificate.

To force the verification, sslmode must be set to either verify-ca to check that the certificate is trusted by the chain, or even verify-full to also check that the name in the certificate matches the name in the libpq connection string.

If you use Dovecot's SQL driver, that might look like this:

connect = host=localhost dbname=mails user=admin password=pass sslmode=verify-full

Only Dovecot is mentioned; I expect there is also at least some MTA, which might need a similar adjustment to its configuration too.

Your client system must also have ~/.postgresql/root.crt file with trusted root CA certificates. Therefore, you must locate the Dovecot's user home directory and place the root certificate there. Alternatively, you may set sslrootcert=/path/to/file parameter to the connection string to specify the file with the trusted root CA certificate, and provide that file instead.

Improve this answer
2
  • 1
    I ended up also adding sslrootcert to the parameters, so all the users who are connecting to the psql instance can verify the certificate. Commented Oct 21, 2024 at 11:01
  • Nice idea, I think the mention of that parameter would be beneficial in the answer, too, so I updated it! Commented Oct 21, 2024 at 11:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.