Michael Fuhr <mike@fuhr.org> writes:
> Was there a change affecting client certificate handling a couple
> of months ago?
Yes, but it was pre-beta3.
However, this being on Windows ... I don't think the SSL code was
enabled at all in the Windows port as of beta3. I find this post-beta3
CVS log entry:
2004-10-06 05:35 momjian
* configure, configure.in, src/backend/libpq/be-secure.c,
src/backend/port/win32/socket.c,
src/backend/postmaster/postmaster.c, src/include/pg_config.h.in,
src/include/port/win32.h: Here is a patch to fix win32 ssl builds.
Summary of changes:
* Links with -leay32 and -lssleay32 instead of crypto and ssl. On
win32, "crypto and ssl" is only used for static linking.
* Initializes SSL in the backend and not just in the postmaster. We
cannot pass the SSL context from the postmaster through the
parameter file, because it contains function pointers.
* Split one error check in be-secure.c. Previously we could not
tell which of three calls actually failed. The previous code also
returned incorrect error messages if SSL_accept() failed - that
function needs to use SSL_get_error() on the return value, can't
just use the error queue.
* Since the win32 implementation uses non-blocking sockets "behind
the scenes" in order to deliver signals correctly, implements a
version of SSL_accept() that can handle this. Also, add a wait
function in case SSL_read or SSL_write() needs more data.
Magnus Hagander
It seems likely to me that the Windows SSL code may still be a brick or
two shy of a load ...
regards, tom lane