This is a discussion on Re: [GENERAL] Client SSL validation using root.crt within the pgsql Hackers forums, part of the PostgreSQL category; --> On Mon, Nov 20, 2006 at 10:30:31PM -0500, Tom Lane wrote: > "Sergio" <sergio.cinos@gmail.com> writes: > > I see ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| On Mon, Nov 20, 2006 at 10:30:31PM -0500, Tom Lane wrote: > "Sergio" <sergio.cinos@gmail.com> writes: > > I see a strange behaviour using root.crt. PostgreSQL always waits a > > client certificate to check agains root.crt. But I set up a > > 'hostnossl' auth line un pg_hba.conf, PostgreSQL still wants a client > > certificate. > > No, not really. The problem is that in the default PGSSLMODE=prefer > behavior, libpq tries an SSL connection first. It's prepared to retry > with a non-SSL connection if it gets a rejection from the server ... > but if OpenSSL fails to establish the connection, it just dies > immediately. It is possible to continue communicating after SSL negotiation failure. If SSL_accept/connect return 0, that means the negotiation failed cleanly and in theory libpq could continue in non-SSL mode. I think long term this would be the nicest solution (no double connections) but it's probably more complicated then looping around again after SSL failure. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFYtUZIB7bNG8LQkwRAsbfAJ9RbxGItKg9RKzgfaYqDF HxVqSHDwCfXg+4 /bFaXcsAaOQ5BLc5U6Ntn9s= =XvvF -----END PGP SIGNATURE----- |
| ||||
| Martijn van Oosterhout <kleptog@svana.org> writes: > It is possible to continue communicating after SSL negotiation failure. > If SSL_accept/connect return 0, that means the negotiation failed > cleanly and in theory libpq could continue in non-SSL mode. We'd have to change the backend too, though, because in existing releases it likewise will drop out on SSL negotiation failure. > I think long term this would be the nicest solution (no double > connections) but it's probably more complicated then looping around > again after SSL failure. I don't think it's that important. If the backend is configured with ssl = off then we already fall through without using an extra connection cycle. The double connection only occurs if both sides think they should use SSL but something goes wrong ... which is probably a situation that needs user attention anyway. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings |