I wrote: > Gustavsson Mikael <mikael.gustavsson@xxxxxxx> 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@xxxxxxx>. 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
