Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-11-30 Thread Bruce Momjian
On Thu, Mar 21, 2013 at 01:42:55PM +0800, Craig Ringer wrote: > On 03/19/2013 09:46 PM, Stephen Frost wrote: > > * Craig Ringer (cr...@2ndquadrant.com) wrote: > >> As far as I'm concerned that's the immediate problem fixed. It may be > >> worth adding a warning on startup if we find non-self-signed

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-20 Thread Craig Ringer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2013 09:46 PM, Stephen Frost wrote: > * Craig Ringer (cr...@2ndquadrant.com) wrote: >> As far as I'm concerned that's the immediate problem fixed. It may be >> worth adding a warning on startup if we find non-self-signed certs in >> root.crt

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-19 Thread Stephen Frost
* Craig Ringer (cr...@2ndquadrant.com) wrote: > As far as I'm concerned that's the immediate problem fixed. It may be > worth adding a warning on startup if we find non-self-signed certs in > root.crt too, something like 'WARNING: Intermediate certificate found in > root.crt. This does not do what

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-19 Thread Craig Ringer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2013 08:39 PM, Stephen Frost wrote: > Craig, > > * Craig Ringer (cr...@2ndquadrant.com) wrote: >> Yep, in most applications I've seen you usually store a list of >> authorized SubjectDNs or you just use your own self-signed root and >> issue

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-19 Thread Stephen Frost
Craig, * Craig Ringer (cr...@2ndquadrant.com) wrote: > Yep, in most applications I've seen you usually store a list of > authorized SubjectDNs or you just use your own self-signed root and > issue certs from it. Even with a self-signed root issuing certs, you need to map the individual cert to a

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-19 Thread Bruce Momjian
On Tue, Mar 19, 2013 at 01:46:32AM -0400, Stephen Frost wrote: > > I guess that suggests we should be calling this something like > > 'ssl_authorized_client_roots'. > > I'm no longer convinced that this really makes sense and I'm a bit > worried about the simple authentication issue which I though

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Craig Ringer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2013 01:46 PM, Stephen Frost wrote: > If you're using a public CA as your > root, then you need to make sure you know how to ensure only the right > people have access, typically be storing in the mapping table the unique > ID issued by the C

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Stephen Frost
Craig, * Craig Ringer (cr...@2ndquadrant.com) wrote: > They are intermediary, but we're dealing with the case where trust and > authorization are not the same thing. Trust stems from the trusted root > in the SSL CA model, but that's a chain of trust for *identity* > (authentication), not *authori

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Craig Ringer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/2013 08:55 PM, Stephen Frost wrote: > Makes sense to me. I'm not particular about the names, but isn't this > set of CAs generally considered intermediary? Eg: 'trusted', ' > intermediate', etc? They are intermediary, but we're dealing with t

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Ian Pilcher
On 03/18/2013 02:01 AM, Craig Ringer wrote: > This appears to match Ian's description of having a validation-only cert > list and a separate list of certs used to verify clients. I'd like to > follow Apache's model: Ready for some more good news? It's possible that I'm missing something, but Apac

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Stephen Frost
Craig, all, * Craig Ringer (cr...@2ndquadrant.com) wrote: > PROBLEM VERIFIED Let me just say "ugh". I've long wondered why we have things set up in such a way that the whole chain has to be in one file, but it didn't occur to me that it'd actually end up causing this issue. In some ways, I real

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Craig Ringer
On 03/18/2013 02:27 PM, Ian Pilcher wrote: > On 03/18/2013 12:07 AM, Craig Ringer wrote: >> So this problem is verified. > * Trusted certificates - What currently goes in the (unfortunately > named) root.crt file. Well, a little unfortunate. It contains roots of *client authentication* trust, w

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-18 Thread Craig Ringer
On 03/18/2013 01:07 PM, Craig Ringer wrote: > System wide installation of the root may allow OpenSSL to discover it > and use it for verification back to the root without having to trust it > to sign clients. I'll do some more checking to see if this is possible > with how Pg uses OpenSSL but I'm i

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-17 Thread Ian Pilcher
On 03/18/2013 12:07 AM, Craig Ringer wrote: > So this problem is verified. Thanks for taking the time to look into this. Good to know I'm not crazy. > What we need to happen instead is for root.crt to contain only the > trusted certificates and have a *separate* file or directory for > intermedi

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-17 Thread Craig Ringer
On 03/09/2013 04:52 PM, Ian Pilcher wrote: > After looking at be-secure.c and investigating the way that OpenSSL > validates certificates, I do not believe that there is any way of > achieving the desired behavior with the current codebase. Test process: SET UP SERVER VERIFIED SSL (NO CLIENT CERT

Re: [GENERAL] [HACKERS] Trust intermediate CA for client certificates

2013-03-17 Thread Craig Ringer
On 03/09/2013 04:52 PM, Ian Pilcher wrote: > 3. Once the root CA certificate is trusted, however, the "bad" client >can also connect by using a certificate chain that includes the >Server CA certificate --"cat bad-client.crt server-ca.crt > >~/.postgresql/postgresql.crt". > > After look