Re: Trust intermediate CA for client certificates

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Ian Pilcher <arequipeno(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, stellr(at)vt(dot)edu, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trust intermediate CA for client certificates
Date: 2013-03-19 13:46:16
Message-ID: 20130319134616.GA4361@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

* Craig Ringer (craig(at)2ndquadrant(dot)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 you expect and your configuration may be
> insecure; see the Client Certificates chapter in the documentation.'

I'm not sure that I follow this logic, unless you're proposing that
intermediate CAs only be allowed to be picked up from system-wide
configuration? That strikes me as overly constrained as I imagine there
are valid configurations today which have intermediate CAs listed, with
the intention that they be available for PG to build the chain from a
client cert that is presented back up to the root. Now, the client
might be able to provide such an intermediate CA cert too (one of the
fun things about SSL is that the client can send any 'missing' certs to
the server, if it has them available..), but it also might not.

> We could then look at using more flexible approaches to match PostgreSQL
> users to client certificates, like regexps or (preferably, IMO)
> DN-component based solutions to extract usernames from cert DNs, etc.
> Various ways to specify *authorization*.

Sure.

> It's looking more and more like the *authentication* side is basically
> "do you trust this CA root not to sign certs for fraudlent/fake
> SubjectDNs or issue intermediate certs that might do so? Trust: include
> it. No trust: Don't." That's what we have now, it just needs to be
> explained better in the docs.

I certainly agree that the docs could be improved in this area. :)

Thanks,

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Farber 2013-03-19 15:10:46 Matching uppercased russian words (\x0410-\x042F) in UTF8 database 8.4.13
Previous Message Bruce Momjian 2013-03-19 13:41:25 Re: Trust intermediate CA for client certificates

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Singer 2013-03-19 14:12:21 Re: pg_upgrade segfaults when given an invalid PGSERVICE value
Previous Message Bruce Momjian 2013-03-19 13:41:25 Re: Trust intermediate CA for client certificates