The certificate hasn’t been issued yet, and the output suggests I need to validate ownership by adding an AAAA record:
The certificate for ai-yp.fly.dev has not been issued yet.
Hostname = ai-yp.fly.dev
DNS Provider = flydns
Certificate Authority = Let’s Encrypt
Issued =
Added to App = 14 hours ago
Source = fly
You are creating a certificate for ai-yp.fly.dev
We are using lets_encrypt for this certificate.
You can validate your ownership of ai-yp.fly.dev by:
1: Adding an AAAA record to your DNS service which reads:
AAAA @
My Goal:
I want to connect to my PostgreSQL database from my Mac using psql with SSL encryption, so that the connection is secure. Here’s the command I plan to use for connecting:
Hi… In general, the app-name.fly.dev domains already have their certificates, and you, the user, needn’t do anything extra in that regard.
It looks like the actual problem might be that you’ve allocated an IPv4 address to the ai-yp app but (perhaps) haven’t yet adjusted its services settings.
Aside: It’s easier and safer to connect using flyctl proxy’s ad hoc Wireguard tunnel…
➜ fly fly ips list --app ai-yp
VERSION IP TYPE REGION CREATED AT
v4 149.248.220.49 public (dedicated, $2/mo) global Oct 14 2024 13:12
v6 fdaa:a:7ffa:0:1::2 private global Oct 14 2024 12:55
Deleting FLY_SCALE_TO_ZERO also did not help for me.
Could I ask you to attempt to connect to my server with SSL? Maybe there is a problem with my network…"
These EOFs during early SSL are indicative of glitches at the edge proxy that Fly maintains.
If the machine is definitely running and you’re not seeing any problems reported in the logs (fly logs -a ai-yp), then I would try temporarily creating a completely new database app. Sometimes the Fly.io infrastructure gets stale metadata, and it’s difficult for us ordinary users to diagnose when that’s happened…
You can probably delete these certificates. At best, they’re doing nothing, and, at worst, they’re confusing the edge proxy…
Your other database app didn’t have custom certificates such as these listed, right? I’m really surprised that attempt failed…
The ams and arn regions have been having sporadic problems lately, now that I think about it. Where did you try the newest one?
Also, are you connecting throughams? You can see this in ~/.fly/config.yml, under wireguard_state. (Don’t post things from in there, incidentally, , since it has encryption details.)
Sorry that didn’t pan out… Several other users have been reporting difficulty connecting to their Postgres databases suddenly, and the official status page is reporting “degraded performance” for at least one aspect of the .fly.dev domains, so this may be a widespread, transient metadata glitch:
We are investigating increased proxy errors for apps communicating over Flycast internal networking
That’s a little different from the feature that you were trying, but it does involve closely related code, as I understand it. It’d probably be worth making another attempt once they’ve marked it fully over…
It’s not the “hairpinning” aspect that the proxy doesn’t like, but rather the fact that some older versions of psql do not send SNI to the TLS server, which is required by the proxy. AFAIK SNI support should be enabled by default for psql clients version 14 and later, but if not, you may try this configuration option on the client side.
Thanks for chiming in! That’s an excellent find… I was stubbornly trying to connect from Debian Bullseye, which is only PG v13.
Using Bookworm instead did indeed fix it:
# psql 'postgres://postgres:<right-password>@minoan-saffron.fly.dev:5432/?sslmode=require'
psql (15.8 (Debian 15.8-0+deb12u1), server 16.4 (Ubuntu 16.4-1.pgdg24.04+1))
WARNING: psql major version 15, server major version 16.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
postgres=# \conninfo
You are connected to database "postgres" as user "postgres"
on host "minoan-saffron.fly.dev" (address "2a09:8280:1::12:abcd:0") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
It doesn’t look like that sslsni knob is available on v13, but this definitely does solve the main mystery, …