This patch has been tested with gmni and Castor; both are able to use
certificates generated in this way. Additional testing can be done by
accessing gemini://markdain.net which is now serving an ECDSA cert.
The curve secp384r1 was picked because other curves would fail during
cert generation or would fail in other ways. For instance, secp256k1
would produce a certificate with shorter keys than 384r1, however no
Gemini client would accept it - nor would `openssl s_client'.
Let's Encrypt uses secp384r1 for their new ECDSA root cert, so that
seemed like a safe choice for something widely supported.
src/tls.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/tls.c b/src/tls.c
index f7ed344..e3653f2 100644
--- a/src/tls.c+++ b/src/tls.c
@@ -23,17 +23,12 @@ tls_host_gencert(struct gmnisrv_tls *tlsconf, struct gmnisrv_host *host,
EVP_PKEY *pkey = EVP_PKEY_new();
- BIGNUM *bn = BN_new();- assert(bn);- BN_set_word(bn, RSA_F4);-- RSA* rsa = RSA_new();- assert(rsa);- int r = RSA_generate_key_ex(rsa, 4096, bn, NULL);+ EC_KEY* ec_key = EC_KEY_new_by_curve_name(NID_secp384r1);+ assert(ec_key);+ int r = EC_KEY_generate_key(ec_key); assert(r == 1);
- BN_free(bn);- EVP_PKEY_assign_RSA(pkey, rsa);+ EVP_PKEY_assign_EC_KEY(pkey, ec_key); X509 * x509 = X509_new();