How to build your own public key infrastructure
blog.cloudflare.com
blog.cloudflare.com
I'm a big fan of DigitalOcean but they don't offer VPCs like AWS does so I always have to create a PKI in order to communicate securely between my droplets. I've always done this with some crappy scripts but I'll definitely give CFSSL a shot for automating this next time.
EDIT: One beef I have with cfssl is the csr_ca.json file. Making the keys in the "names" object less obscure would do wonders for readability.
I'm curious if you used something like the blockchain (but not bitcoin necessarily) to have a public ledger of published public keys (identities) would that problem be essentially solved? (IE if the keys and any signing for a web of trust be on a distributed public ledger, then you could be reasonably sure that you're dealing with the person really behind that public key?)
A few things to look at (not exhaustive):
http://www.certificate-transparency.org/
An important early formulation of this possibility was Aaron Swartz's, in "Squaring Zooko's Triangle":
http://www.aaronsw.com/weblog/squarezooko
Everyone has different ideas about how most efficiently and safely to make public records append-only and achieve distributed consensus, and also what kind of records to put in to the system and what rules to use for validating updates. One way in which proposals have diverged is whether to use blockchain-like distributed consensus for storing and distributing keys, or just for adding transparency to trusted authorities' behavior.
If the NSA can throw enough computing power at it and seize control of consensus to determine which keys are authoritative, then your whole PKI is useless.
I repeat: consensus is not a suitable mechanism for authority. Consensus has many other uses. Would you use a watermelon to lock a door?
2) Offline key management -- e.g. a laptop in a safe -- was the low end solution for a long time. However, there are a lot of reasons why you want an online CA now
3) Just keeping a key in memory on a machine (doing nothing special) obviously exposes you to several risks: a) Administrator (can be remote; incl compromise of laptop of admin) b) Anyone who gains root on the box c) Application-level security issues (ranging from key leakage to just compromising the application. d) Physical-access cold boot (which can be more exciting in a virtualized environment)
There are a bunch of ways to improve #3, although it will remain worse than #1 or #2.
a) Simply run the keys in a different process; this protects you against some minimal things, and if you use a PKCS 11 interface, makes upgrading to an HSM later easier.
b) Different user, with a defined interface
c) Different VM
d) Physically separate machines communicating over a bidirectional link (you could do this as two ethernet connections)
e) Two one-way links bound to specific programs (e.g. serial); much harder to compromise both this way. You'd need to compromise the "send commands" program, and "receive commands" program, and the "send response" program. They can be very limited in what they do.
Limiting admin access to physical-presence, or at the very least via a secure pathway which isn't direct to the machine (e.g. a console server which logs) goes a long way, too.