On Thu, Mar 30, 2017 at 10:31:06PM +1030, Jack Burton wrote: <snip> > Personally, I'm leaning towards either local CRL file checking in > httpd (with minimal changes to libtls), or passing through enough data > to the let the fastcgi responders take whichever approach they want.
In all my experience with client certificates (whether with browsers, IPSec, or custom applications), I've usually relied on the ability to embed data in the client certificate, such as domains, e-mail addresses, UUIDs, etc. That often entirely removed the need to do database queries from application code or to maintain and expose any centralized data store (except the CRL, of course) to network-facing nodes. In other words, client certificates not only solve the authentication problem, but can also help solve the authorization problem, and in many cases solve it completely. My $0.02: client certificates aren't particularly useful unless the certificate itself is made available to the application. Knowing that a certificate has a valid signature is only part of the equation, and not even the most useful part. Unlike server certificates, however, there's no single authorization check (i.e. matching the embedded domain name to the queried URL) that can be implemented by middle-ware. The semantics of embedded data are specific to a service and often ad hoc. Basically, anything short of passing through the entire certificate is going to be severely limiting and frustrating, to the point of uselessness. And as a practical matter, parsing out and passing through a subset of certificate data is likely going to require more complex code than just passing the entire certificate to the application.
