cfssl
cfssl copied to clipboard
cloudflare
Secure CA private key storage
Is there currently any way to securely store the CA private key, while still using the cfssl CLI, specifically cfssl serve or multirootca?
Apparently PKCS#11 support in the CLI was removed in #519. Now, in order to use PKCS#11 with cfssl, I suppose one would have to use https://github.com/letsencrypt/pkcs11key and develop something like cfssl/cli/serve with pkcs11 options?
There are mentions of experimental Red October support in multirootca. I am not sure of its current status, but I believe it is not currently working. In multiroot/config, the priv variable is not set.
Are there other alternatives? Have I missed something?
Thanks for all the hard work!
We are planning on spinning the PKCS#11 enabled version of cfssl into another repository, pretty much as you described (letsencrypt/pkcs11key, pkcs11uri and cfssl/cli/serve with pkcs11 options). Until then you can either put that together yourself or vendor an older version of CFSSL.
As for Red October, we have version working but have not fully merged it into multirootca.
Note: It may not be necessary to spin off PKCS#11 support into another repository. You can follow the example of database/sql and provide a registry for key loaders. That way you can build a cli with or without PKCS#11 support, depending on a build tag that controls whether pkcs11key is imported and registered as a key loader method.
Thank you for those answers. If I can get some time to work on the PKCS#11 support before you do, then perhaps I'll be able to contribute something back.
@tgenovese I am waiting for this support too. It seems odd that PKCS#11 would be a separate repository when it should be just another option of running the server. In my configuration I am hoping to have a remote server for signing only with PKCS#11 support. @jsha will take your hints and see what it looks like to implement my use case. Thanks again folks for all the hard work.
@fhossain: The backstory on why PKCS#11 is not included by default is that it is implemented in cgo and requires libtool-ltdl, which not everyone has on their system, so including it by default would make building cfssl more cumbersome for most folks.
@jsha got it. As @alberts suggests, I would think build tag would be fine for this. I don't mind using -tag pkcs11 or something similar to get a non-default build with PKCS#11 support and have the rest of the code shared. I do worry if I wrote my own signing server that will not be api compatible with -remote in the long run. What is the plan for keeping the PKCS#11 enabled version of cfssl on the second repository in synch with the main version?
@fhossain To provide some context: we had build tags for pkcs 11 (at one point default enabled and at another default disabled). While in theory it would work great and be wonderful, in practice it broke a lot of things and caused a number of build problems. A quick glance through the closed issues and PRs that mention pkcs 11 should give you some more background on this.
If you want to build your own signing server, what you need to do is to use the pkcs11key package to build a signer.Signer, then supply that to the various API components (e.g., api/signhandler/NewHandlerFromSigner. Doing it this way means you don't have to worry about remaining API compatible.
Has anyone in the community written a PoC that uses pkcs11key as part of a signer.Signer? I have cfssl installed a long with letsencrypt/pkcs11key and trying to perform some basic signing operations outside of using the individual libraries.
Boulder uses pkcs11key as a signer.Signer. You can see an example here of how we instantiate it: https://github.com/letsencrypt/boulder/blob/master/cmd/boulder-ca/main.go#L66-L102, and here of how we use it with cfssl: https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L140-L175.
You can also see a more narrow use case at https://github.com/letsencrypt/boulder/blob/master/cmd/single-ocsp/main.go.
I have gone and re-implemented pkcs11key in to cfssl1.3.2 as a proof of concept in case anyone is interested. See https://github.com/jimmypw/cfssl/tree/1.3.2-pkcs11. I wouldn't recommend using this code in production. It works in my setup but it has not been tested to any extent.
What is the appetite for PKCS11 integration in CFSSL? This issue has been open for a few years now with not very much movement. I for one have a requirement for it and I'm happy to devote a bit of time to it.
I would like to use cfssl with hsm in production. Are there any efforts to enable it in further releases?
