svenstaro/miniserve

Is there any chance of supporting "EC" format private keys?

IdyllicHappiness opened this issue · 5 comments

IdyllicHappiness commented

I just want to start by saying I really like the project and am very grateful for the work the team has done! (i.e. I'm very much not complaining, not that anyone has the right to on free, open-source projects anyway 🙂)

This "issue" described below is not blocking me, I've found a way around it and automated it, but I was wondering if support for "EC" format private keys could be built in to avoid this step.

If it's out of scope, or it's just a case of me using a format that is not supported for a good reason, that's 100% fine.

I recently started using a tool called lego (repo) in place of certbot as it allows me to create a wildcard certificate with a one line command thanks to its DuckDNS DNS-challenge support.

After getting the certificates I've been going through my home server applications and dropping the new certificate files in to see them working correctly without issue.

However I had a little bit of a hiccup with miniserve whereby it gave the following error.

Error: No supported private key in file

Running file on it, it returns PEM EC private key, and the contents look as such.

-----BEGIN EC PRIVATE KEY-----
key_content_here
-----END EC PRIVATE KEY-----

I converted it to a non-EC based private key using the following code (I'd previously just created a PFX file for Plex, and as I struggled to find material online to directly convert an EC private key to a non-EC private key, I just went the very roundabout route of pulling it from this newly created PFX, anyhow my silly code aside, the takeaway point is that it creates a valid non-EC private key)

openssl pkcs12 -in foobar.duckdns.org.pfx -passin pass:foobar -nocerts -nodes -out foobar.duckdns.org_non_ec.key
sed -i -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' # not required, but just removed the seemingly redundant "bag attributes" headers

And it has the format you'll be familiar with.

-----BEGIN PRIVATE KEY-----
key_content_here
-----END PRIVATE KEY-----

With this non-EC private key miniserve works a charm again.

Thanks in advance for any thoughts.

svenstaro commented

Hey, this should be relatively easy to support and concede that this was an oversight. rustls supports this so I'll take a look at this a bit later.

  • 👍1
svenstaro commented

I added support. Could you check whether this works for you? I can then cut a release

IdyllicHappiness commented

Sure thing, I’ll get back to you tomorrow. Thanks for the work!

svenstaro commented

So how's it looking?

IdyllicHappiness commented

Works a charm, thank you very much!

# repo version, non-EC manually converted key
/usr/bin/miniserve --tls-cert ${partialFilePath}.crt --tls-key ${partialFilePath}_non_ec.key -u -p 50080 -- ${shareFilePath}

# EXPECTATION: Success
# RESULT: Meets expectation


# repo version, original EC key
/usr/bin/miniserve --tls-cert ${partialFilePath}.crt --tls-key ${partialFilePath}.key -u -p 50080 -- ${shareFilePath}

# EXPECTATION: Failure
# RESULT: As expected, get error message "Error: No supported private key in file" and exits immediately


# 6464935adf0c3121f7bc297d01e6b011ed2f3216-master version, non-EC manually converted key
target/release/miniserve --tls-cert ${partialFilePath}.crt --tls-key ${partialFilePath}_non_ec.key -u -p 50080 -- ${shareFilePath}

# EXPECTATION: Success
# RESULT: Meets expectation


# 6464935adf0c3121f7bc297d01e6b011ed2f3216-master version, original EC key
target/release/miniserve --tls-cert ${partialFilePath}.crt --tls-key ${partialFilePath}.key -u -p 50080 -- ${shareFilePath}

# EXPECTATION: Success
# RESULT: Meets expectation
  • 👍1