Add config option to restrict roots that can sign clients

[csstaub]

We might have a trust store with roots that we trust for connecting to admin/ui endpoints, but not for regular API endpoints. Need a way to distinguish between these, e.g. by optionally allow for pinning to a specific root for API clients.

[madtrax]

Agree, which also implies to have a dedicated CRL for these client certificates.

[mcpherrinm]

We could issue automation certs off a separate root or intermediate and drop the automationenabled column in the database too, if we wanted. (Or automatically fill that column?). Not sure that's as worthwhile a change though.

This change will allow us to allow client certs for admin users in keywhiz.cli, which would be nicer than having to type your ldap credentials on a server -- currently an annoying pain point.

[csstaub]

I suppose the easiest solution would be to run all the UI endpoints on an entirely different port, and then have a separate dropwizard config for it.

[madtrax]

The current scenario I have in mind is that if your Keywhiz server is using a SSL certificate (TLS Web Server Authentication) issued by a different root CA than your client certificates (TLS Web Client Authentication) the client connections will fail due to the fact that the CRL you are using is the one of your web server certificate root CA (otherwise the server will fail to start).

So it's not really related to the admin/UI endpoints I believe.

[csstaub]

If you're using a CRL file, wouldn't you just be able to concatenate the CRLs together? It's just a series of PEM blocks after all.

[madtrax]

Yes it's possible but I am under the impression that concatenating CRL isn't supposed to be valid. (see http://openssl.6102.n7.nabble.com/concatenate-two-CRL-s-td21119.html)

The concatenation of two digitally signed CRLs is not a
valid digitally signed CRL. Some applications may
happen to have code to explicitly support this hack, but
that ability could actually be a security hole as an enemy
could concatenate an outdated and a current CRL, fooling
such applications into thinking the revocations in the old
CRL still apply (Which would be relevant if a CA
temporarily "revokes" half-issued certificates as part of its
procedures).

So yes it does work (it's what I am doing now) but I am not sure if we should consider that as a hack or not. An easy solution would be to disable the CRL check for the server certificate too.

Thanks for the quick reply @csstaub

[mcpherrinm]

@madtrax We use Keywhiz with a different server and client roots in our production deploys. You just have to set "validateCerts: false" in your dropwizard applicationConnectors config, so that it doesn't check the validity of its own certs.

[madtrax]

@mcpherrinm perfect, I will document that somewhere and use this solution. Thank you!

[mcpherrinm]

I've added a comment and that option to the dev config in #186
I'll probably revert that option once this issue is closed, though.