Skip site navigation (1) Skip section navigation (2)

A solution to the SSL customizing problem

From: Ulrich Meis <kenobi(at)halifax(dot)rwth-aachen(dot)de>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: A solution to the SSL customizing problem
Date: 2004-10-11 15:52:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
I have read previous posts and the proposal that the user should supply a 
SSLSocketFactory. Besides the obvious question - how - I see an additional 
problem in that approach:

It's anything but user friendly.
All you want is a secure connection to postgres and you end up digging deeply 
into the JSSE spec.
Even if all you want is turn validation off, you will have to have some 
knowledge of the spec.
The really hard bit comes when you want to retrieve the certificate from the 
server. You are using SSL because you are concerned about security, so you 
probably want checking. Now you will have to give your own TrustManager 
implementation that saves the certificate received for checking. Furthermore, 
you will have to save that certificate somehow and you'll end up handling 
keystores and stuff. What an effort just for this feature!

I propose a different solution.
There are three modes I can think of when opening a connection:

1. Disabling validation.

Not interesting for a user with security concerns - you loose half of SSL's 

2. Enabling validation (standard)
The problem is that you need to get your hands on the server's certificate.
If you distribute an applet for a single server, like I do, you can ship the 
server's certificate with your applet. One thing you certainly don't want is 
to tell people how to insert it with a command line tool (keytool) and so a 
nice solution is to provide it in a keystore and point jdbc to it. 
Furthermore you are likely not to have write permissions on the standard 
keystore (if you want to update it in your applet) because it is in a subdir 
of java_home.

3. Trust and save (disable validation and save received key)
Same as with openssl and known_hosts, you accept the host the first time you 
connect, save its certificate and use the standard mode from then on. 
Implementation of this feature is easier within the driver because you have 
access to the SSL connection and can retrieve the certificate(s). As a user 
you can't just pull it off the postgres port because postgres doesn't start 
off in SSL mode. You will have to implement a TrustManager.

What I did for the driver is the following: Anologously to and

I introduced

org.postgresql.trustStore and org.postgresql.trustStorePassword

Now you can specify your own trustStore for pgjdbc connections.
If it doesn't exist, it will be created for you.

Additionally I introduced the trust-and-save mode.

Currently I look for a property org.postgresql.ssl_trustandsave but this would 
better be handled in a URL parameter like "ssl_trustandsave".

When the driver is in trust-and-save mode, it will trust any server you 
connect to and save its certificate in the trustStore.

In an application, you would first run in normal mode. If the connection 
fails, you ask the user if he wants to trust the unknown key and if he 
agrees, you connect again with ssl_trustandsave mode activated and the key is 
saved. In subsequent connections, you turn ssl_trustandsave off.


I introduced a class org.postgresql.util.PGSSLSocketFactory and changed one 
line in org.postgresql.Driver and method makeSSL from factory = (;


org.postgresql.util.PGSSLSocketFactory factory = 

What do you think?

Kind Regards,


Description: text/x-java (7.5 KB)


pgsql-jdbc by date

Next:From: Tom LaneDate: 2004-10-11 16:40:05
Subject: Re: A solution to the SSL customizing problem
Previous:From: Peter EisentrautDate: 2004-10-11 10:31:27
Subject: Re: Using gettext

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group