Re: SSL certificates issue

От:

Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>

Дата:

23 августа 2011 г. в 04:29:34

Il giorno lun, 22/08/2011 alle 09.37 -0400, Tom Lane ha scritto:
> Asia  writes:
> > Now the issue is then when using libpq it was enough to have only root certificate in server's root.crt and it worked fine.
> > But when I tried using the same with JDBC it turned out that I need to put whole chain (2 certs) of Intermediate CA 1 in server's root.crt.
[...]
> In the JDBC case you'd need to put all those certs into the client's
> keystore, which I'm afraid I don't know the details of doing.  Possibly
> somebody on pgsql-jdbc could help you with that.

you should import CA certificate in your JRE ca certstore with commands:

cd $JAVA_HOME/jre/lib/security
keytool -import -trustcacerts -alias $YOURCAALIAS \
	-file $YOURCACERTFILE -keystore cacerts

I usually store in client and server certificates the whole chain from
primary CA.

Bye,
Giuseppe

Re: SSL certificates issue

От:

Adrian Klaver <adrian.klaver@gmail.com>

Дата:

7 сентября 2011 г. в 10:59:52

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

Re: SSL certificates issue

От:

Andrew Sullivan <ajs@crankycanuck.ca>

Дата:

7 сентября 2011 г. в 13:37:22

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

Re: SSL certificates issue

От:

Radosław Smogura <rsmogura@softperience.eu>

Дата:

7 сентября 2011 г. в 13:32:12

Asia  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

Re: SSL certificates issue

От:

Radosław Smogura <rsmogura@softperience.eu>

Дата:

7 сентября 2011 г. в 07:27:24

On Wed, 07 Sep 2011 12:03:45 +0200, Asia wrote:
>> Asia  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&a=commitdiff&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

Re: SSL certificates issue

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

22 августа 2011 г. в 10:37:38

Asia  writes:
> Now the issue is then when using libpq it was enough to have only root certificate in server's root.crt and it worked fine.
> But when I tried using the same with JDBC it turned out that I need to put whole chain (2 certs) of Intermediate CA 1 in server's root.crt.

This is poor configuration, because every certificate listed in root.crt
is considered fully trusted for every purpose.  It's best to keep only
top-level root certs in root.crt.  Instead, put the full chain of
certificates into the client's postgresql.crt, as per the manual:

: In some cases, the client certificate might be signed by an
: "intermediate" certificate authority, rather than one that is directly
: trusted by the server. To use such a certificate, append the certificate
: of the signing authority to the postgresql.crt file, then its parent
: authority's certificate, and so on up to a "root" authority that is
: trusted by the server. The root certificate should be included in every
: case where postgresql.crt contains more than one certificate.

In the JDBC case you'd need to put all those certs into the client's
keystore, which I'm afraid I don't know the details of doing.  Possibly
somebody on pgsql-jdbc could help you with that.

			regards, tom lane

SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

22 августа 2011 г. в 06:33:15

Recently I have been working on implementation of mutual SSL authentication between our application and PostgreSQL database.
I managed to make it work wih "ssl=true" connection option and "clientcert=1" flags in pg_hba.conf. Moreover I managed to make it work with C++ application using libpq and Java application using postgresql JDBC driver.

The only concern I have is some discrepancy between the way libpq and JDBC works. It seems that libpq is less restrictive than JDBC with standard
built-in SSLSocketFactory.
The following schema describes some information about my certs:

    Client                                  Server
    postgresql.crt                       server.crt
    postgresql.key                      server.key
    root.crt                               root.crt
    
where postgresql.crt is singed by Intermediate CA 1
         server.crt is signed     by Intermediate CA 2
 Intermediate CA 1 and Intermediate CA 2 are chain certs both singed by the same root certificate
         root.crt - root certificate that signed Intermediate CA1 and Intermediate CA 2 (which was enough for libpq but not enough for JDBC)
      
Now the issue is then when using libpq it was enough to have only root certificate in server's root.crt and it worked fine.
But when I tried using the same with JDBC it turned out that I need to put whole chain (2 certs) of Intermediate CA 1 in server's root.crt.

All I need is the confirmation whether this is working as designed or this is possibly libpq bug?

Kind Regards,
Joanna

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

23 августа 2011 г. в 03:43:12

Thank you for your reply. I agree that this configuration could be better and this is why I sent my post.

There is still one concern remaining. As I said I have working configuration with libpq and jdbc. For jdbc I created keystore, that is properly used with connection ssl=on parameter and clientcert=1 in og_hba.conf, everything works fine.

The issue is why for libpq it is enough to have only one lowest level root certificate matched besides the fact that certificate postgresql.crt that is presented to server contains actually 3 certs (2 from Intermediate authority with lowest level root). 
For JDBC it was not enough, I had to put whole CA chain to be able to create succesfull connection. It seems lipqg does not support chained CA's.

I need to confirm that this is working as designed (I will be able to adjust my solution depending on the answer).

Thank you.

Kind regards,
Joanna

W dniu 2011-08-22 15:37:28 użytkownik Tom Lane  napisał:
> Asia  writes:
> > Now the issue is then when using libpq it was enough to have only root certificate in server's root.crt and it worked fine.
> > But when I tried using the same with JDBC it turned out that I need to put whole chain (2 certs) of Intermediate CA 1 in server's root.crt.
> 
> This is poor configuration, because every certificate listed in root.crt
> is considered fully trusted for every purpose.  It's best to keep only
> top-level root certs in root.crt.  Instead, put the full chain of
> certificates into the client's postgresql.crt, as per the manual:
> 
> : In some cases, the client certificate might be signed by an
> : "intermediate" certificate authority, rather than one that is directly
> : trusted by the server. To use such a certificate, append the certificate
> : of the signing authority to the postgresql.crt file, then its parent
> : authority's certificate, and so on up to a "root" authority that is
> : trusted by the server. The root certificate should be included in every
> : case where postgresql.crt contains more than one certificate.
> 
> In the JDBC case you'd need to put all those certs into the client's
> keystore, which I'm afraid I don't know the details of doing.  Possibly
> somebody on pgsql-jdbc could help you with that.
> 
> 			regards, tom lane
>

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

7 сентября 2011 г. в 07:07:13

> Asia  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&a=commitdiff&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

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

7 сентября 2011 г. в 11:04:13

> 
> 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

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

5 сентября 2011 г. в 09:27:22

> Asia  writes:
> > Now the issue is then when using libpq it was enough to have only root certificate in server's root.crt and it worked fine.
> > But when I tried using the same with JDBC it turned out that I need to put whole chain (2 certs) of Intermediate CA 1 in server's root.crt.
> 
> This is poor configuration, because every certificate listed in root.crt
> is considered fully trusted for every purpose.  It's best to keep only
> top-level root certs in root.crt.  Instead, put the full chain of
> certificates into the client's postgresql.crt, as per the manual:
> 
> : In some cases, the client certificate might be signed by an
> : "intermediate" certificate authority, rather than one that is directly
> : trusted by the server. To use such a certificate, append the certificate
> : of the signing authority to the postgresql.crt file, then its parent
> : authority's certificate, and so on up to a "root" authority that is
> : trusted by the server. The root certificate should be included in every
> : case where postgresql.crt contains more than one certificate.
> 
> In the JDBC case you'd need to put all those certs into the client's
> keystore, which I'm afraid I don't know the details of doing.  Possibly
> somebody on pgsql-jdbc could help you with that.
> 
> 			regards, tom lane
> 

Hi Tom,

I have analyzed your reply thoroughly in my implementation, but unfortunately either I make something wrong with the configuration or it does not work like described in the doc.

When I put top-level CA (just to remind intermediate CA is a 2 certs chain) certificate in root.crt on client I receive following error when connecting:

SSL error: tlsv1 alert unknown ca

When I do the same on server (with original root.crt on client) I receive following error when connecting with server's root.crt containing only top level CA:

SSL error: certificate verify failed

I was not actually asking for the details ho to do it with JDBC, since I got it working with proper keystore and truststore and "clientcert=1". I was asking why jdbc works differently than libpq - it should have similar behavior (JDBC uses standard ssl implementation from Java, I did not find custom implementation from Postgres). JDBC requires clients full CA chain in server's root.crt while libpq does not. The question is why and is it right ?

Would you please let me know what possibly I am doing wrong and confirm that chained CA's are supported?

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. 

Please advise.

Kind regards,
Joanna

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

7 сентября 2011 г. в 11:41:10

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  napisał:
> Asia  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
>

Re: SSL certificates issue

От:

Asia <asia123321@op.pl>

Дата:

7 сентября 2011 г. в 08:53:10

> 
> 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

Re: SSL certificates issue

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

7 сентября 2011 г. в 11:06:23

Asia  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

Re: SSL certificates issue

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

7 сентября 2011 г. в 12:20:51

Asia  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

Re: SSL certificates issue

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

5 сентября 2011 г. в 13:30:53

Asia  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&a=commitdiff&h=4ed4b6c54

			regards, tom lane

Re: SSL certificates issue

От:

Radosław Smogura <rsmogura@softperience.eu>

Дата:

7 сентября 2011 г. в 10:32:41

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