Does MPG support TLS, or only 6PN encryption?

Questions / Help
,
1

Trying to use MPG pooled connections with hostname-authenticated TLS (sslmode=verify-full) from a Fly Machine.

MPG v1

Pooled endpoint negotiates TLS 1.3, but serves:

  • private postgres-operator-ca, absent from Debian system trust;
  • certificate SANs containing only internal *.svc.cluster.local PgBouncer names—not advertised pgbouncer.<cluster>.flympg.net.

Adding the CA cannot fix the hostname mismatch. Same client/image/network passes verify-full against the v1 direct endpoint.

Fresh MPG v2 control

Tested generated pooled and direct endpoints using psql 16.15, OpenSSL 3.0.20 and asyncpg 0.31.0:

  • psql sslmode=require: both endpoints failed 3/3 with SSL error: unexpected eof while reading;
  • openssl s_client -starttls postgres: EOF before certificate;
  • asyncpg ssl="verify-full": connection reset during TLS upgrade;
  • sslmode=disable: both endpoints connected successfully.

This appears inconsistent with the MPG client documentation saying SSL is enabled by default on all MPG connections. That might mean only 6PN/WireGuard transport encryption—not PostgreSQL protocol TLS—but I do not want to assume.

Has anyone:

  1. successfully used PostgreSQL protocol TLS with MPG v2?
  2. found Fly’s supported CA and correct hostname/SNI for verify-full?
  3. encountered the v1 pooled certificate hostname mismatch?
  4. found a workaround besides the direct endpoint or disabling PostgreSQL TLS verification?
2

I can’t reproduce this (v2 cluster):

root@148e3145cd0228:/app# psql "postgresql://$credentials@direct.d2gznoqg1680pkm8.flympg.net:5432/fly-db?sslmode=verify-full&sslrootcert=system"
psql (17.11 (Debian 17.11-0+deb13u1), server 17.10 (Debian 17.10-1.pgdg13+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: postgresql)
Type "help" for help.

fly-db=>
\q
root@148e3145cd0228:/app# openssl s_client -starttls postgres -connect direct.d2gznoqg1680pkm8.flympg.net:5432 2>&1 | grep subject
subject=CN=*.d2gznoqg1680pkm8.flympg.net

could you create a ticket regarding the specific cluster(s) that are having this issue so our MPG folks can take a look?

3

Created T-19455. That test is only direct.*, but my primary blocker is pgbouncer.*. Thank you!

5

same thing with pgbouncer endpoint:

root@148e3145cd0228:/app# psql "postgresql://$credentials@pgbouncer.d2gznoqg1680pkm8.flympg.net:5432/fly-db?sslmode=verify-full&sslrootcert=system"
psql (17.11 (Debian 17.11-0+deb13u1), server 17.10 (Debian 17.10-1.pgdg13+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: postgresql)
Type "help" for help.

fly-db=>
\q
root@148e3145cd0228:/app# openssl s_client -starttls postgres -connect pgbouncer.d2gznoqg1680pkm8.flympg.net:5432 2>&1 | grep subject
subject=CN=*.d2gznoqg1680pkm8.flympg.net
6

Thanks! I just tested a fresh MPG v2 cluster in IAD, connecting from a Fly Machine. Used psql 17.11 with sslmode=verify-full&sslrootcert=system, but both pooled and direct endpoints failed 9/9 even after waiting >10 minutes.

Also tried TLS 1.2/1.3 and SNI/ALPN variants. Same failure: connection closes after ClientHello, before sending any certificate. OpenSSL trace:
```
no peer certificate available
SSL handshake has read 1 bytes and written 1594 bytes
SSL_connect:SSLv3/TLS write client hello
unexpected eof while reading
```

The same client successfully verified our existing v1 direct endpoint.

I noticed your server is 17.10, while mine was 17.11. Wanted to try your version too, but MPG only lets me choose the major version (17), not 17.10 (see flydocs). Could there be an image or provisioning difference?

7

it looks like there’s a 15 minute delay between creation of MPG cluster and TLS being set up. this is of course unintentional and we’re looking at getting if fixed.

8

Yep, that was it. Thanks! After migrating our cluster to MPG v2, TLS started working about 15 minutes after preparation.