* Craig Ringer (craig@xxxxxxxxxxxxxxx) 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
Attachment:
signature.asc
Description: Digital signature
