Puppet

+1

OCSP is supported in ruby at least since 1.8.6. I’m not sure about the previous versions.

Daniel Pittman wrote:

Brice, this looks pretty awesome. It has taken a while to get to looking at, so a couple of things:

Can you retarget this at master – this is way too big a change to introduce in a stable release, but it looks like a great feature to add.

No problem. I will do that ASAP. It was my intention to target Telly anyway.

How mature do you think this is?

I’d say it is beta quality. I tested all I could, and the code is pretty quite isolated from the puppet core that when disabled it shouldn’t introduce any side-effect.

Note that to properly test the setup you need a separate CA server than your master (otherwise CRL will be much more useful and faster). So this feature is more useful to larger deployments than the average.

You note that you didn’t test a Passenger based setup, and that you don’t cache the CRL. How significant do you think those issues are?

For the passenger setup, we just need to perform testing on this stack. At that time I didn’t had a passenger setup ready for testing the whole code. The problem I was outlining with the CRL caching is the following. The OCSP responder checks the revocation of a given certificate serial number in this CRL. Due to the nature of the CRL, the revocation check is done linearly, and the CRL is reloaded on every request. I implemented a cache on the client side to mitigate this issue. To properly fix this, we would also need a server side CRL cache, and/or load the CRL and index it in memory, or use a different on-disk revocation storage (ie a secure database of some sort). I believe, if proven that it is a problem, we can add server-side CRL indexation/caching quite easily.

I didn’t went that far, because I didn’t really stress test the OCSP responder.

Is this a mature commit that just needs some testing, or do you think that we are likely to uncover bugs in testing it?

I believe it just needs more testing and production workload. I don’t think we’ll hit major bugs. But it might also require a thorough code review.

Finally, do you have a sketch for how we could test that this feature works at a high level? What are the edge cases we should be validating?

There are basically three tests to perform (with a CA only server, 1 master, and 1 client):

• no certificates revoked, check that the client can gets its catalog.
• revoke client certificate on the CA server: check the server rejects the client
• revoke server certificate (with valid client cert): check the client rejects the server

This has to be done on the 3 stacks we support for the master: passenger, mongrel and webrick (we don’t care what the CA server is running on). The reason we have to test the 3 stacks is that every stack uses a different way to check for the OCSP status (for instance webrick does it in the certificate store callback, but the 2 others are not the SSL endpoint and thus don’t have access to these information directly). On mongrel or passenger setup, the ssl endpoint configuration should be adjusted to send the client certificate to Puppet.

With those answers, and a branch targetted at master, I am happy to take this and get it in place for Telly.

OK, that sounds great, thanks!

Brice Figureau wrote:

Daniel Pittman wrote:

Brice, this looks pretty awesome. It has taken a while to get to looking at, so a couple of things:

Can you retarget this at master – this is way too big a change to introduce in a stable release, but it looks like a great feature to add.

No problem. I will do that ASAP. It was my intention to target Telly anyway.

Awesome. Thanks for those details; that is more or less the answers I expected, which is great. Before it lands we will absolutely be doing a thorough code review, and thank you very much for implementing this.