-----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 certs from it. > > Even with a self-signed root issuing certs, you need to map the > individual cert to a PG user in some fashion. >
The more I look a this, the more it looks like trying to use intermediate CAs as authentication roots is largely wrong anyway. We should document this with something like: NOTE: Only self-signed root CA certificates should be added to ssl_ca_file. If you add an intermediate CA certificate (one that's not self-signed) then PostgreSQL will not be able to validate client certificates against it because it will not have access to the full certificate chain. You can't fix that by adding the full certificate chain then PostgreSQL will then accept client certificates trusted by any member of the chain, including the root, so the effect is the same as placing only the root certificate in the file. It is not currently possible to trust certificates signed by an intermediate CA but not the parents in its certificate chain. ... plus some explanation that having a valid trusted cert doesn't mean you're authorized for access, you still have to meet the requrements in pg_hba.conf, have a valid username/password or match an authorized certificate DN (depending on config), etc. 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.' 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*. 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. - -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRSGoOAAoJELBXNkqjr+S26esIALSmgX6/4lC+J7W3YPDpl1DE UJsSGc46oBZbC/5xDwBELh2Tg+fqzIe+Kmx+EpsC20MaGinqEz9iwTb2M7vTFhxh nvAkp1Em8MhR6lvCKITjPnDBCv7yQ7K3yTAfHO+LU2J1t3eVhStpXh71/73pRLoQ p3SAUwO0EBnZFdY2HVLPABK7tpjuf5Mpn0QFR9T+KvsgcP9QXiV0UTFI0IxlQrpE NRlJfPwkoYAweISTACrDwqJHJ3sL/qLdOQ8l4BCsiwtqynX7fPhxmDUuBXrOTqlS dwW9ZkBJ9jvXjF3PPk1t0oujlMJGBC4Y7xgIb0Kd87Vyv/OTkWE4XKriDhIH6oQ= =f3qr -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
