Re: SSL certificates issue

Asia <asia123321@op.pl> writes:

I would expect to have only one top-level CA cert in server's and client's root.crt and it was not possible to configure with 2-level intermediate CA.

This seems a little confused, since in your previous message you stated
that libpq worked correctly and JDBC did not, and now you seem to be
saying the opposite.

As far as libpq goes, I would expect it to function correctly in 9.0 and
up (and it did function correctly, last I tested it). Previous releases
will not do this nicely, for lack of this patch:
http://git.postgresql.org/gitweb/?p=postgresql.git&amp;a=commitdiff&amp;h=4ed4b6c54

regards, tom lane

Asia <asia123321@op.pl> writes:

I would expect to have only one top-level CA cert in server's and client's root.crt and it was not possible to configure with 2-level intermediate CA.

This seems a little confused, since in your previous message you stated
that libpq worked correctly and JDBC did not, and now you seem to be
saying the opposite.

As far as libpq goes, I would expect it to function correctly in 9.0 and
up (and it did function correctly, last I tested it). Previous releases
will not do this nicely, for lack of this patch:
http://git.postgresql.org/gitweb/?p=postgresql.git&amp;a=commitdiff&amp;h=4ed4b6c54

regards, tom lane

I apologise then, it seems I was not clear enough when explaining my issue.

I am using PostgreSQL, version 9.0.

I have all of it (libpq and jdbc) working, however I have some doubts about the correctness of my configuration.

The situation is more or less like following:

Client intermediate CA (root.crt): C1 -> C2, Client cert: C1 -> C2 ->C3

Server intermediate CA (root.crt): C1 -> S1, Server Cert: C1 -> S1 -> S2

I always use clientcert=1 in pg_hba to force mutual SSL.

Now with the above configuration libpq connects fine. But when I tried to use jdbc it requires me to append client's intermediate CA - "C1 -> C2"
to server's root.crt. So server's root.crt content looks like follows:

C1 -> S1 -> C1 -> C2

Then jdbc conenction works fine and the change does not affect libpq - it works fine like before.

So my point was general why the behavior for libpq and jdbc driver is not common (probably we would need some custom implementation of Java SSL facory
for PostgreSQL) - both types of connection have different cert configuration what I believe could be better when it was common.

And the second issue is that you wrote that it should be enough to put to-level CA certs. So I left only C1 in server's root.crt, restarted server
and received following error during connection:

SSL error: certificate verify failed

The question is how to do it correctly?

Please advise.

Kind regards,
Joanna

On Wed, 07 Sep 2011 12:03:45 +0200, Asia wrote:

Asia <asia123321@op.pl> writes:

I would expect to have only one top-level CA cert in server's and

client's root.crt and it was not possible to configure with 2-level
intermediate CA.

This seems a little confused, since in your previous message you
stated
that libpq worked correctly and JDBC did not, and now you seem to be
saying the opposite.

As far as libpq goes, I would expect it to function correctly in 9.0
and
up (and it did function correctly, last I tested it). Previous
releases
will not do this nicely, for lack of this patch:

http://git.postgresql.org/gitweb/?p=postgresql.git&amp;a=commitdiff&amp;h=4ed4b6c54

regards, tom lane

I apologise then, it seems I was not clear enough when explaining my
issue.

I am using PostgreSQL, version 9.0.

I have all of it (libpq and jdbc) working, however I have some doubts
about the correctness of my configuration.

The situation is more or less like following:

Client intermediate CA (root.crt): C1 -> C2, Client cert: C1 -> C2
->C3

Server intermediate CA (root.crt): C1 -> S1, Server Cert: C1 -> S1 ->
S2

I always use clientcert=1 in pg_hba to force mutual SSL.

Now with the above configuration libpq connects fine. But when I
tried to use jdbc it requires me to append client's intermediate CA -
"C1 -> C2"
to server's root.crt. So server's root.crt content looks like
follows:

C1 -> S1 -> C1 -> C2

Then jdbc conenction works fine and the change does not affect libpq
- it works fine like before.

So my point was general why the behavior for libpq and jdbc driver is
not common (probably we would need some custom implementation of Java
SSL facory
for PostgreSQL) - both types of connection have different cert
configuration what I believe could be better when it was common.

And the second issue is that you wrote that it should be enough to
put to-level CA certs. So I left only C1 in server's root.crt,
restarted server
and received following error during connection:

SSL error: certificate verify failed

The question is how to do it correctly?

Please advise.

Kind regards,
Joanna

I think problem is as follows, server sends to client certificates it
can accept (as accepted parents), without intermediate CA, Java sees
only top-level cert and tries to find client cert issued directly by
top-level CA, I may only assume, that without intermediate CA you will
be able to auth against any cert signed by top-level CA (this may cause
small security hole as well).

I think this is not needed, but I suggest You too check cert "policies"
with v3 extensions.

Java is really pedantic, about security.

Regards,
Radek

I think problem is as follows, server sends to client certificates it
can accept (as accepted parents), without intermediate CA, Java sees
only top-level cert and tries to find client cert issued directly by
top-level CA, I may only assume, that without intermediate CA you will
be able to auth against any cert signed by top-level CA (this may cause
small security hole as well).

I think this is not needed, but I suggest You too check cert "policies"
with v3 extensions.

Java is really pedantic, about security.

Regards,
Radek

The problem is that I believe that this configuration could be better but I cannot put part
of CA chain in root.crt as it was advised.
For Java it all depends on current SSL Factory implementation, I was using the default one.
If I wrote my own implementation I would probably be able to have common with libpq,
requiring the least info, configuration (but actually I would prefer to avoid it).

Kind regards,
Joanna

On Wed, 07 Sep 2011 13:49:30 +0200, Asia wrote:

I think problem is as follows, server sends to client certificates
it
can accept (as accepted parents), without intermediate CA, Java sees
only top-level cert and tries to find client cert issued directly by
top-level CA, I may only assume, that without intermediate CA you
will
be able to auth against any cert signed by top-level CA (this may
cause
small security hole as well).

I think this is not needed, but I suggest You too check cert
"policies"
with v3 extensions.

Java is really pedantic, about security.

Regards,
Radek

The problem is that I believe that this configuration could be better
but I cannot put part
of CA chain in root.crt as it was advised.
For Java it all depends on current SSL Factory implementation, I was
using the default one.
If I wrote my own implementation I would probably be able to have
common with libpq,
requiring the least info, configuration (but actually I would prefer
to avoid it).

Kind regards,
Joanna

I personally haven't tired SSL for PostgreSQL but, I think, You should
put in root.crt only intermediate certificate (C1 - from prev post), so
all and only all "sub-certs" of intermediate CA will be able to
establish connection (paranoic security).

Putting intermediate CAs as trusted in Java keystore may be solution,
but I'm not sure if in situation of cert invalidation, such cert will be
rejected.

If you want to write SSL Factory, you should re-implement KeyManager
only, to give ability of extended search.

Regards,
Radek

On Wednesday, September 07, 2011 4:49:30 am Asia wrote:

The problem is that I believe that this configuration could be better but I
cannot put part of CA chain in root.crt as it was advised.
For Java it all depends on current SSL Factory implementation, I was using
the default one. If I wrote my own implementation I would probably be able
to have common with libpq, requiring the least info, configuration (but
actually I would prefer to avoid it).

You might want to take a look at the below and see if it helps:

http://jdbc.postgresql.org/documentation/head/ssl-client.html

Kind regards,
Joanna

--
Adrian Klaver
adrian.klaver@gmail.com

I personally haven't tired SSL for PostgreSQL but, I think, You should
put in root.crt only intermediate certificate (C1 - from prev post), so
all and only all "sub-certs" of intermediate CA will be able to
establish connection (paranoic security).

Putting intermediate CAs as trusted in Java keystore may be solution,
but I'm not sure if in situation of cert invalidation, such cert will be
rejected.

If you want to write SSL Factory, you should re-implement KeyManager
only, to give ability of extended search.

Regards,
Radek

I have already tried with only C1 in root.crt but unfortunately it does not work. I get error message that cert is invalid. It seems that chained CA's are not supported in a way we would like to have it done. I would prefer to have number of trusted certs in root.crt limited as much as possible, but as I said it does not work.

About Java, I would need to analyze the libpq code and implement KeyManager in a similar way - this is surely possible but not necessarily preferred solution ;-)

Kind regards,
Joanna

Asia <asia123321@op.pl> writes:

The problem is that I believe that this configuration could be better but I cannot put part
of CA chain in root.crt as it was advised.
For Java it all depends on current SSL Factory implementation, I was using the default one.
If I wrote my own implementation I would probably be able to have common with libpq,
requiring the least info, configuration (but actually I would prefer to avoid it).

You would be better off to ask about this on the pgsql-jdbc list; the
people who actually work with JDBC tend to hang out there. I'm not sure
how carefully any of them follow pgsql-general.

regards, tom lane

I have a feeling that jdbc list is not the right list to ask why libpq does not work when I
put top-level CA cert from CA having two certs in root.crt while you stated it would be
proper configuration.

There are 2 related threads here: one with consistency between libpq and jdbc driver and the other about
how libpq works with chained CA's.

Kind regards,
Joanna

W dniu 2011-09-07 16:06:10 użytkownik Tom Lane <tgl@sss.pgh.pa.us> napisał:

Asia <asia123321@op.pl> writes:

I have a feeling that jdbc list is not the right list to ask why libpq does not work when I
put top-level CA cert from CA having two certs in root.crt while you stated it would be
proper configuration.

What is a "CA having two certs"? AFAIK, there is no such animal.

regards, tom lane

Asia <asia123321@op.pl> Wednesday 07 of September 2011 16:00:39

I personally haven't tired SSL for PostgreSQL but, I think, You should
put in root.crt only intermediate certificate (C1 - from prev post), so
all and only all "sub-certs" of intermediate CA will be able to
establish connection (paranoic security).

Putting intermediate CAs as trusted in Java keystore may be solution,
but I'm not sure if in situation of cert invalidation, such cert will be
rejected.

If you want to write SSL Factory, you should re-implement KeyManager
only, to give ability of extended search.

Regards,
Radek

I have already tried with only C1 in root.crt but unfortunately it does
not work. I get error message that cert is invalid. It seems that chained
CA's are not supported in a way we would like to have it done. I would
prefer to have number of trusted certs in root.crt limited as much as
possible, but as I said it does not work.

About Java, I would need to analyze the libpq code and implement KeyManager
in a similar way - this is surely possible but not necessarily preferred
solution ;-)

Kind regards,
Joanna

I bearly looked at Javav SSL implementation, and it should support certificate
chain, even if intermediate cert isn't presented by server (not in root.crt),
until You have valid chain in key/trust store. I found, and You may try to
turn it on, "javax.net.debug=all" to see debug info of cert matching.

Only one thing comes to me, why it doesn't works, Your intermediate cert may
have no issuer DN

Regards,
Radek

On Wed, Sep 07, 2011 at 04:37:24PM +0200, Asia wrote:

put top-level CA cert from CA having two certs in root.crt

[. . .]

how libpq works with chained CA's.

"Two certs" and "chained CAs" are completely different problems. What
are you trying to do, exactly?

A

--
Andrew Sullivan
ajs@crankycanuck.ca