Re: Support for cert auth in JDBC

It is true that anyone who knows the right Java APIs can put that
factory together with little pain. I just think that the average user
shouldn't have to bother about it.

Also, some use cases do not allow to use the default keystore and trust
store for everything.

Just for example, this is the setup in my application:
* 1 Cert for some server component that speaks TLS
* 1 Cert for the pgsql client component
* 1 Cert for the JNDI client component (connects to LDAP)

So we end up with 3 different keystores (and maybe trust stores too),
all of which may have different passwords. It is actually not that much
of a big deal to use, but the 'defaults' won't help us here too much I
think.

Using this kind of configurable setup allows much simpler deployments
than having to change stuff in a central keystore (which may have other
keys to NOT mess up with), and allows to test in different environments
and very easily.

Maybe our use case is overkill. Anyways, I'm attaching the code as I
have it now. I tested the code from which this one comes from, but this
incarnation isn't tested. I'll put more time on it once I hear back from
the maintainers. :)

I'd love to have some comments on this rough version also (CVS diff
didn't do anything with this file, so there is no point to include that).

P.S. Undocumented detail: we need to put the user's name in the
connection settings anyway, as it won't work without it.

Regards,

Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On Wednesday 18 May 2011 12:32 PM, Craig Ringer wrote:
> On 18/05/2011 2:06 PM, Marc-André Laverdière wrote:
>> Hello,
>>
>> This implementations allows to specify which keystore and which
>> truststore to load. This allows certificate authentication in the
>> application easily.
>
> It's already pretty easy. You can:
>
> - Load your keys in the standard keystore;
> - Populate a new JECKSf-format keystore with your cert and key and use
> the javax.net.ssl.trustStore etc system properties on the cmdline or via
> System.setProperty() to use that store instead of the default store;
> - Provide your own javax.net.ssl.SSLSocketFactory that wraps the default
> implementation with any additional behavior you need.
>
> PgJDBC could use some documentation/examples for the latter option, but
> it shouldn't need any changes to the PgJDBC code.
>
>> The Java SSL API is not very well known to the JDBC driver developers
>> and we would be interested in any interesting and generally useful
>> extensions that you have implemented using this mechanism. Specifically
>> it would be nice to be able to provide client certificates to be
>> validated by the server.
>> </quote>
>>
>> What I'm talking about is this factory referred to in the last paragraph.
>
> OK, so you've just written an easy-to-use canned SSLSocketFactory that
> loads client certificates from an application-configurable
> keystore/truststore?
>
> I did this in my app to allow it to use a PKCS#12 format X.509
> certificate directly and it was a pretty low-pain procedure. It'd be
> nice to have more general purpose examples in the PgJDBC sources,
> though. Maybe I should dig out the examples I posted to this mailing
> list a while ago and submit them, too?
>
> I'm not one of the PgJDBC developers, but I'd be happy to have a look at
> what you've done and see if I can be of any help, provide useful
> feedback, etc.
>
> It'd probably be best if you published your work as a patch ("diff")
> against PgJDBC CVS HEAD, posting the patch to this mailing list so
> people can look at it and try it. Make sure the email you send the patch
> in clearly explains the reason for any change to the existing PgJDBC
> code, and if you do change the core PgJDBC code make sure it passes any
> tests and that it compiles under the oldest supported JDK.
>