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

[zenhack]

Issue by kuba
Sunday Apr 17, 2016 at 21:22 GMT
Originally opened as kuba/simp_le#105

---

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 Question: main page says the build fails - will current version work? #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.

---

kuba included the following code: https://github.com/kuba/simp_le/pull/105/commits

[zenhack]

Comment by notr1ch
Tuesday May 24, 2016 at 17:36 GMT

---

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.

[zenhack]

Comment by kuba
Sunday May 29, 2016 at 14:33 GMT

---

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...

[zenhack]

Comment by notr1ch
Wednesday Jun 08, 2016 at 19:37 GMT

---

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.