Re: [HACKERS] Trust intermediate CA for client certificates - Mailing list pgsql-general

Craig,

* Craig Ringer (craig@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.

> I'm pretty sure I've seen tools match on part of the DN, like the
> organisation field, but since I can't remember *where* I'm not sure
> that's all that useful.

Looking at what other tools do and how they handle this question would
certainly be a good idea.

> I don't know about "very rare" but it's certainly not common outside
> very large orgs. I tried to find a CA that'd let me issue intermediate
> client certs for 2ndQuadrant but found nobody that'd do it for
> certificate volumes less than several thousand new certs a month. I'd
> been using intermediate CAs based on my own self-signed CA root quite
> heavily in infrastructure elsewhere I was rather surprised that the same
> sort of thing wasn't easily available for public CAs.

It's pretty simple, really- issuing certs is how the public CAs make
their money.  If they give you a CA cert that can issue certs, they're
cut out of the loop.

> I get the impression it's fairly common in internal infrastructure,
> especially with the cert management tools offered by Microsoft Active
> Directory servers, but have no strong information to substantiate this.
> Nor do I know whether we need to support this mode of operation.

In general, CAs view intermediate certs as a way to provide automated
systems while having their self-signed root private key highly
protected.  The intermediate CAs therefore have a shorter life-span and
end up changing much more frequently than the root certs (though root
certs certainly also do change, but it's much more painful).  That's one
of the reasons that they're bad to use as part of the authentication
criteria.

The problem with trying to use intermediate CAs as a way of dividing up
organizational responsibility is simply that there's very few systems
out there which will support that kind of configuration, from what I've
seen.  Wrt Active Directory this problem is actually very well solved
through use of Kerberos, where you have multiple realms, directional
trust between the realms, and most tools (including PG) understand that
a principal is the combination of username@REALM and let you authorize
based on that.

> BTW, This discussion has made me realise that I know less about SSL/TLS
> and X.509 certificate extensions than I'd like to when dealing with this
> topic. In particular, I don't know whether a CA can issue an
> intermediate CA with extensions that restrict it to validly signing only
> host certificates for hosts under a particular domain or
> user-identifying client certs with CNs under a particular organisation -
> and whether, if such extensions exist, applications actually check them
> when verifying the certificate trust chain.

You can set flags on certificates but I've not seen the kind of complex
restrictions that you're describing.  Remember that anything that the CA
sets for an intermediate CA cert would have to be checked by whatever
software is doing the certificate validation, meaning that you'd have to
make sure all your certificate-based software is updated to do that kind
of validation (and do it in a consistent way, or you'd get all kinds of
fun failures).

> Ugh, that's not something I've ever had the ... privilege ... to deal
> with before.

I worked for the company that built the original federal bridge
software. :)  I wasn't directly involved in that project, but I
certainly gained some understanding of the complexities through working
with the folks who were.

> Only for using intermediate certs as authorization roots, and it may be
> reasonable to say "we don't support that, use an authorized DN list". Or
> come up with a better solution like checking attributes of the SubjectDN
> for authorization purposes after validating the signature chain to prove
> authenticity.

I think it'd be valuable to distinguish "trusted CAs" from "intermediate
CAs" in PG explicitly (as I recall, you can already do this by simply
ensuring that your OpenSSL config is set up correctly for the system
wide defaults).  That's what most serious SSL users will be familiar
with anyway.  I'm on the fence about if only supporting a list of
"trusted CAs" (through the cert files that we currently have) rises to
the level of being a security issue, but we should at least update the
documentation to reflect that all CAs listed in the file are fully
trusted and plan to provide an intermediate CA list option.  To be
honest, our entire SSL support mechanism could really use some work and
it'd be great if we had some folks looking into it seriously.  One of
the problems we've long had is the dependency on OpenSSL (yes, it's a
problem) and it'd be good to consider, if we're changing the SSL
configuration, how we could make it easier to introduce other SSL
libraries in the future.

> Certificate fingerprint? Easily obtained via most client UIs and via

They change too much.  This is the trade-off that you end up having to
deal with- either you depend on the DN/CN, which can end up being
duplicately issued by a given root CA, or you depend on the fingerprint
and then have to re-enroll individuals whenever they get a new cert.
This isn't an easy problem to solve, when dealing with the US ACES
program, we could never get them to give us a "unique-to-a-person"
identifier, the best we got was the DN.  That changes when an individual
changes organizations, which happens stupidly frequently in government,
but (on rare occation..) it may also come with an actual change in
responsibility, such that the individual shouldn't have access any
longer.  Being able to map certs based on the DN instead of just the CN
would, imv, be a valuable improvment to the PG SSL options.  We'd
probably want to support that on a per-map basis and not just globally.

> However, if I was managing a group large enough to want cert auth I'd
> want to be able to specify something like:
>
>     SubjectDNMatches: C=*, ST=*, L=*, O=MyCompany, CN=*

If we had a way to use the DN in pg_ident.conf, you could use a regex to
do the matching.

> ... in which case there'd no longer be a need to restrict trust to
> intermediate CAs, you'd just trust the root and restrict the authorized
> SubjectDNs.

In general, I'm open to doing it all kinds of ways; more options here
would be better than what we've currently got.  I would put splitting
the CA cert chain file into trusted-CAs and intermediate-CAs as the
higher priority here, followed by allowing the use of the DN for the
mapping to PG user, and perhaps lastly something that tried to tie
into a specific path, chain, or intermediate CA, as I don't see a very
big use case for that.

    Thanks,

        Stephen