Re: [GENERAL] Libpq and multithreading
I am sure that I am using seperate threads with seperate connection objects and libpq is compiled to be threadsafe. I get access violation both with ssl and without it (without ssl it seems to be more stable, however afer several hundred connects/disconnects it fails). J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Libpq and multithreading
It is not possible because connection is local variable in both thread functions, no common variables are used. I checked that it also crashes without SSL. Two threads connecting to the same server, different databases. Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Libpq and multithreading
I am using 2 threads, each declares seperate PGconn conenction object. It connects e.g. 60 times, one connection from one thread, the other connection from the other thread, usually one after each other. And it fails at 61'st connection with access violation. I already tried with PQconnect and PQsetdbLogin. I am using mututal SSL authentication with this connections, maybe this is the case? Kind regards, Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Libpq and multithreading
Hello, I am trying to use libpq in two threads, the issue is that I am getting access violation after several successful connections. Each thread connects to different db and disconnects immediately after making a conenction. So my question is if this is supported by libpq? Is it possible to use it in more than one thread and make connections at the same time? Kind regards, Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
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 > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
> > 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
> > 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
> 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
> 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SSL certificates issue
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 > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] SSL certificates issue
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Universal certificate for verify-full ssl connection
Hi, I am trying to generate self-signed certificate for full ssl authentication. I need to have universal version of this certificate for development purposes (so any client can connect with any postgresql server with ssl on and verify-full flag). I am using IP while connecting, I mean host=. However verify-full connection works only in case "Common Name" in certificate contains only fully qualified IP address, when I try to set CN as * (asterisk) I receive error: server common name "*" does not match hostname "my_ip" According to the documentation here : http://www.postgresql.org/docs/current/static/libpq-ssl.html "If the connection is made using an IP address instead of a host name, the IP address will be matched (without doing any DNS lookups). " Would you please advise what I am doing wrong? Or maybe there is other way to generate wildcard certificate ? Or maybe this is a possible bug? Thanks in advance ! Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Universal certificate for verify-full ssl connection
Hi, I am trying to generate self-signed certificate for full ssl authentication. I need to have universal version of this certificate for development purposes (so any client can connect with any postgresql server with ssl on). I am using IP while connecting, I mean host=. However verify-full connection works only in case "Common Name" in certificate contains only fully qualified IP address, when I try to set CN as * (asterisk) I receive error: server common name "*" does not match hostname "my_ip" According to the documentation here : http://www.postgresql.org/docs/current/static/libpq-ssl.html "If the connection is made using an IP address instead of a host name, the IP address will be matched (without doing any DNS lookups). " Would you please advise what I am doing wrong? Or maybe there is other way to generate wildcard certificate ? Thanks in advance ! Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
