I wrote:
> Gustavsson Mikael <mikael.gustavsson@smhi.se> writes:
>> So if i set gssencmode=disable on my pgsql-13 to postgres 13 server connection i get an SSL connection.
> It looks like, if there is a credentials cache and gssencmode isn't
> explicitly disabled, we try GSS first. If the server refuses that:
> ...
> that is, it decides the connection it has is good enough. This
> is not OK if SSL should have been used.
No, I misread the code; what will happen next is that an SSL connection
will be tried. At least, it looks like that should happen, and it does
happen for me.
However: it is true (and undocumented, so we have at least a docs bug
to fix) that v12-and-later libpq will try for GSS encryption first,
and if it succeeds then it will not consider using SSL, regardless of
sslmode. So about 95% of your report could be explained by assuming
that you have a working Kerberos environment and the newer libpq is
preferring GSS encryption over SSL. There is just one thing this
theory is failing to explain: instead of "SSL connection", psql
should have printed "GSSAPI-encrypted connection" in your test
shown in <d3ab9042bce34aae85d323d69e3ee430@smhi.se>. It didn't,
so this can't be the true explanation. I think what must be
happening is that libpq is trying for GSS (hence you have at least
a credentials cache somewhere), failing to establish it, and then
for some reason advancing to the startup-packet step without
trying for SSL. But I can't see how to get the state machine to
do that.
Have you got any environment variables, service files, etc
that would affect libpq's behavior?
regards, tom lane