On Mon, Dec 2, 2013 at 12:44:08PM -0500, Bruce Momjian wrote:
> On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote:
> > > Drat, you're quite right. I've always included the full certificate
> > > chain in client certs but it's in no way required.
> > >
> > > I guess that pretty much me
On Mon, Dec 2, 2013 at 05:35:06PM -0500, Andrew Dunstan wrote:
>
> On 12/02/2013 04:17 PM, Tom Lane wrote:
> >Bruce Momjian writes:
> >>Sorry, I should have said:
> >>Tom is saying that for his openssl version, a client that passed
> >>an intermediate certificate had to supply a certific
* Bruce Momjian (br...@momjian.us) wrote:
> Uh, this thread actually started with Ian's feature request, and has
> changed to document the current behavior.
Whoops, apologies for that then- I clearly came into it (or perhaps more
accurately, was brought into it) after the start of the thread. I'm
On Mon, Dec 2, 2013 at 04:56:56PM -0500, Stephen Frost wrote:
> * Ian Pilcher (arequip...@gmail.com) wrote:
> > > In any case, the idea that this is somehow OpenSSL's fault and another
> > > implementation of the same protocol wouldn't have the same issue sounds
> > > pretty silly.
> >
> > Actual
* Andrew Dunstan (and...@dunslane.net) wrote:
> But it does need to be signed by a trusted signatory. At least in my
> test script (pretty ugly, but shown below for completeness), the
> Intermediate CA cert is signed with the Root cert rather than being
> self-signed as the Root cert is, and so if
On 12/02/2013 04:17 PM, Tom Lane wrote:
Bruce Momjian writes:
Sorry, I should have said:
Tom is saying that for his openssl version, a client that passed
an intermediate certificate had to supply a certificate _matching_
something in the remote root.crt, not just signed
* Ian Pilcher (arequip...@gmail.com) wrote:
> > In any case, the idea that this is somehow OpenSSL's fault and another
> > implementation of the same protocol wouldn't have the same issue sounds
> > pretty silly.
>
> Actually other implementations do this. In fact, a flag was added to
> OpenSSL f
* Ian Pilcher (arequip...@gmail.com) wrote:
> On 12/02/2013 03:15 PM, Stephen Frost wrote:
> > That isn't at *all* accurate. Authorization is handled by pg_ident and
> > PG's role and grant system. We are only using OpenSSL's trust of the
> > certificate for authentication.
>
> OK, how do I conf
On Mon, Dec 2, 2013 at 03:19:43PM -0600, Ian Pilcher wrote:
> On 12/02/2013 02:32 PM, Tom Lane wrote:
> > Ian Pilcher writes:
> >> I'm not sure what you're asking. The desired behavior (IMO) would be to
> >> accept client certificates signed by some intermediate CAs without
> >> accepting any cl
Ian Pilcher writes:
> BTW, you can't just "list the certs of the intermediate CAs you do
> trust"; you have to put the root CA certificate into root.crt in order
> for OpenSSL to build a complete chain,
I believe you are mistaken. OpenSSL just wants a chain to one of the
certs you've told it to
On Mon, Dec 2, 2013 at 04:17:57PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Sorry, I should have said:
>
> > Tom is saying that for his openssl version, a client that passed
> > an intermediate certificate had to supply a certificate _matching_
> > something in the remote ro
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > At least I think that was the issue, rather than requiring the client to
> > supply a "root" certificate, meaning the client can supply an
> > intermediate or root certificicate, as long as it appears in the
> > root.crt file on th
On 12/02/2013 04:17 PM, Tom Lane wrote:
Bruce Momjian writes:
Sorry, I should have said:
Tom is saying that for his openssl version, a client that passed
an intermediate certificate had to supply a certificate _matching_
something in the remote root.crt, not just signed
On 12/02/2013 03:15 PM, Stephen Frost wrote:
> That isn't at *all* accurate. Authorization is handled by pg_ident and
> PG's role and grant system. We are only using OpenSSL's trust of the
> certificate for authentication.
OK, how do I configure Postgres to only allow connections when the
client
On 12/02/2013 02:32 PM, Tom Lane wrote:
> Ian Pilcher writes:
>> I'm not sure what you're asking. The desired behavior (IMO) would be to
>> accept client certificates signed by some intermediate CAs without
>> accepting any client certificate that can present a chain back to the
>> trusted root.
* Bruce Momjian (br...@momjian.us) wrote:
> Sorry, I should have said:
>
> Tom is saying that for his openssl version, a client that passed
> an intermediate certificate had to supply a certificate _matching_
> something in the remote root.crt, not just signed by it.
>
> At leas
Bruce Momjian writes:
> Sorry, I should have said:
> Tom is saying that for his openssl version, a client that passed
> an intermediate certificate had to supply a certificate _matching_
> something in the remote root.crt, not just signed by it.
> At least I think that was the
On Mon, Dec 2, 2013 at 04:12:13PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Dec 2, 2013 at 03:57:45PM -0500, Andrew Dunstan wrote:
> > >
> > > On 12/02/2013 03:44 PM, Tom Lane wrote:
> > > >Bruce Momjian writes:
> > > >>Let me ask a simple question ---
* Ian Pilcher (arequip...@gmail.com) wrote:
> On 12/02/2013 02:29 PM, Andrew Dunstan wrote:
> > Wouldn't that amount to only partially trusting the root? It seems kinda
> > odd. In any case, It's not something I think Postgres needs to solve.
>
> I think that the fundamental problem is that authen
On 12/02/2013 02:29 PM, Andrew Dunstan wrote:
> Wouldn't that amount to only partially trusting the root? It seems kinda
> odd. In any case, It's not something I think Postgres needs to solve.
I think that the fundamental problem is that authentication and
authorization are being conflated. From
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Dec 2, 2013 at 03:57:45PM -0500, Andrew Dunstan wrote:
> >
> > On 12/02/2013 03:44 PM, Tom Lane wrote:
> > >Bruce Momjian writes:
> > >>Let me ask a simple question --- can
> > >>you put only the client cert on the client (postgresql.crt) and o
* Bruce Momjian (br...@momjian.us) wrote:
> Yes, this was my understanding. Let me ask a simple question --- can
> you put only the client cert on the client (postgresql.crt) and only the
> root cert on the server (root.crt), and will it work?
Only if the client cert is signed directly by the roo
On Mon, Dec 2, 2013 at 03:57:45PM -0500, Andrew Dunstan wrote:
>
> On 12/02/2013 03:44 PM, Tom Lane wrote:
> >Bruce Momjian writes:
> >>Let me ask a simple question --- can
> >>you put only the client cert on the client (postgresql.crt) and only the
> >>root cert on the server (root.crt), and wi
On Mon, Dec 2, 2013 at 03:44:18PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, this was my understanding. Let me ask a simple question --- can
> > you put only the client cert on the client (postgresql.crt) and only the
> > root cert on the server (root.crt), and will it work?
>
> Ye
On 12/02/2013 03:44 PM, Tom Lane wrote:
Bruce Momjian writes:
Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt), and will it work?
Yes, that's surely always worked.
Not if the client has been sign
* Ian Pilcher (arequip...@gmail.com) wrote:
> On 12/02/2013 02:17 PM, Tom Lane wrote:
> > Ian Pilcher writes:
> >> Yes. And the problem is that there is no way to prevent OpenSSL from
> >> accepting intermediate certificates supplied by the client. As a
> >> result, the server cannot accept clie
On Mon, Dec 2, 2013 at 03:07:48PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
> >> I see that you removed the sentence
> >> The root
> >> certificate should be included in every case where
> >> postgresql.crt contains more than one
Bruce Momjian writes:
> Yes, this was my understanding. Let me ask a simple question --- can
> you put only the client cert on the client (postgresql.crt) and only the
> root cert on the server (root.crt), and will it work?
Yes, that's surely always worked.
> I think Tom's question is whether O
On Mon, Dec 2, 2013 at 03:01:25PM -0500, Andrew Dunstan wrote:
> >I don't fully understand the issues but the discussion seens to indicate
> >this. Am I missing something? Should I run some tests?
> >
>
> AIUI, you need a complete chain from one end to the other. So the
> cert being checked can
Ian Pilcher writes:
> On 12/02/2013 02:17 PM, Tom Lane wrote:
>> Isn't that sort of the point?
> I'm not sure what you're asking. The desired behavior (IMO) would be to
> accept client certificates signed by some intermediate CAs without
> accepting any client certificate that can present a chai
On 12/02/2013 03:21 PM, Ian Pilcher wrote:
On 12/02/2013 02:17 PM, Tom Lane wrote:
Ian Pilcher writes:
Yes. And the problem is that there is no way to prevent OpenSSL from
accepting intermediate certificates supplied by the client. As a
result, the server cannot accept client certificates s
On 12/02/2013 02:17 PM, Tom Lane wrote:
> Ian Pilcher writes:
>> Yes. And the problem is that there is no way to prevent OpenSSL from
>> accepting intermediate certificates supplied by the client. As a
>> result, the server cannot accept client certificates signed by one
>> intermediate CA witho
Ian Pilcher writes:
> Yes. And the problem is that there is no way to prevent OpenSSL from
> accepting intermediate certificates supplied by the client. As a
> result, the server cannot accept client certificates signed by one
> intermediate CA without also accepting *any* client certificate tha
On 12/02/2013 02:01 PM, Andrew Dunstan wrote:
> AIUI, you need a complete chain from one end to the other. So the cert
> being checked can include the intermediate cert in what it sends, or it
> can be in the root.crt at the other end, but one way or another, the
> checking end needs a complete cha
Bruce Momjian writes:
> On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
>> I see that you removed the sentence
>> The root
>> certificate should be included in every case where
>> postgresql.crt contains more than one certificate.
> I don't fully understand the issues but the discussion
On 12/02/2013 02:45 PM, Bruce Momjian wrote:
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
Bruce Momjian writes:
I have updated the patch, attached, to be clearer about the requirement
that intermediate certificates need a chain to root certificates.
I see that you removed the se
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have updated the patch, attached, to be clearer about the requirement
> > that intermediate certificates need a chain to root certificates.
>
> I see that you removed the sentence
>
>The root
>certifi
Bruce Momjian writes:
> I have updated the patch, attached, to be clearer about the requirement
> that intermediate certificates need a chain to root certificates.
I see that you removed the sentence
The root
certificate should be included in every case where
postgresql.crt contains mor
On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote:
> > Drat, you're quite right. I've always included the full certificate
> > chain in client certs but it's in no way required.
> >
> > I guess that pretty much means maintaining the status quo and documenting
> > it better.
>
> I have
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
-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
* 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
On Tue, Mar 19, 2013 at 09:37:18PM +0800, Craig Ringer wrote:
> 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
-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
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
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
-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
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
-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
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
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
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
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
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
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
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
On 03/07/2013 12:42 PM, Ray Stell wrote:
> What Tom said works for me. Here is a page that gives an example and I think
> it demonstrates that the root CA does not allow everybody in the gate, the
> chain has to be in place:
>
> http://stackoverflow.com/questions/1456034/trouble-understanding-
57 matches
Mail list logo
