On 08/06/2014 08:37 PM, Jeff Janes wrote:
> But now it looks like 0002 needs a rebase....
I've committed the refactoring patch, and here's a rebased and improved
version of the Windows SChannel implementation over that.
Server-side support is now implemented too, but it's all very crude and
work-in-progress. CRLs are not supported, intermediary CAs are not
supported, and probably many other bells and whistles are missing too.
But the basics work, including cert authentication. Consider this a
Proof of Concept.
One issue came up with managing private keys: In the server, it's
necessary to import the private key into a permanent key container
that's managed by the Windows Crypto API. That can be done
programmatically (as I do in the patch), but the keys are permanently
stored in the system (in the user's profile). They will be left behind
even if you completely delete the data directory. That's not the end of
the world, but it would be nicer if we could use some kind of a
temporary key container that only lives in memory, but the Crypto API
doesn't seem to have such a concept. You can acquire an ephemeral
context by passing the CRYPT_VERIFYCONTEXT flag to CryptAcquireContext
function, and that's exactly what I'm doing in the client, but that
method doesn't seem to work when acting as an SSL server.
Also, the key container needs to be given a name, or we can use the
default container, but either way all the keys are shared among all
applications that use the same container. We'll have to figure out how
to set that up so that there are no conflicts, if you try to use the
same server certificate for two PostgreSQL instances running on the same
host (useful while developing/testing replication).
This isn't a showstopper, but needs some thought. As the patch stands,
it uses a single key container called "PostgreSQL server key container",
and makes no attempt to delete the keys after they're no longer used.
That works, but it leaves the key lying on the system.
- Heikki
