CSR instead of cert key (fixes #13, #53)

[kuba]

This PR substantially changes API for simp_le and will break existing customers

1. Instead of accepting -f key.pem (or -f key.der) it accepts -f csr.pem (-f csr.der) and expects the client to generate CSR (cf. examples/generate_csr.sh).
2. It reads domain names from the CSR instead of -d.
3. Only one webroot can be specified at a time (as a positional argument) instead of --default_root or -d exmaple.com:root syntax, so in case of multi-domain certificates customer is expected to arrange the file hierarchy (e.g. using symlinks).
4. Moreover, the webroot must now be specified including .well-known/acme-challenge (fixes #53).

It's not yet ready, but I hope to get it finished in O(week). Posting it here in advance, so that interested parties get an early notification about breaking changes.

[notr1ch]

Will this be merged soon or is the csr branch safe to use in production? The latest version of nginx supports multiple certificate types so I'm just waiting on a way to generate the certificates.

[kuba]

I'm hoping to merge this soon. I've been distracted from this for a little while, so I don't remember what's left to be done. Maybe it's production ready and I was just afraid of breaking users...

[notr1ch]

I ended up trying to use this branch, but seem to be stuck with an "Error unmarshaling certificate request" from acme when trying to use a CSR with an ECDSA key. Searching the LE forums seems to indicate this is caused if you have a missing extension request, but I have SAN in there so I'm not sure what's happening.

The CSR is pretty simple - one hostname, secp256k1, SHA256. The same settings with an RSA key worked fine. I tried adding explicit secp256k1 parameters but this didn't help. In case it's my mistake, it would be a nice feature to add client-side validation of the certificate to explain what exactly is missing (on that note, a missing SAN throws an assert instead of a descriptive message).

-----BEGIN CERTIFICATE REQUEST----- MIHtMIGUAgEAMBExDzANBgNVBAMMBnItMS5jaDBWMBAGByqGSM49AgEGBSuBBAAK A0IABJgigKi8DMYg13g74/ayVPdyC+G3AcxDeHg2RZx1uILxYQnm3LZIEr4R+eai TQwaT8n0FBeCBYUGV3HdrhFSXdCgJDAiBgkqhkiG9w0BCQ4xFTATMBEGA1UdEQQK MAiCBnItMS5jaDAKBggqhkjOPQQDAgNIADBFAiEAsFWO1X0farfMM0YfneasKkQA fR5u0V7paZjTDxXaHH4CIDhqGfC0bMQ4lCxUi8eXJHBwCqYfpt42dvicBNHYiZo2 -----END CERTIFICATE REQUEST-----

Update: Fixed! I was using secp256k1 when I should have been using prime256v1.