qtun doesn't work when using ECC certificate

[dnomd343]

For example use the following command:

# This is a ECC certificate
shell> head -n 1 /etc/ssl/certs/343.re/privkey.pem
-----BEGIN EC PRIVATE KEY-----
shell> ss-libev-server -s 0.0.0.0 -p 12345 -k dnomd343 -m aes-256-ctr --plugin qtun-server --plugin-opts "cert=/etc/ssl/certs/343.re/fullchain.pem;key=/etc/ssl/certs/343.re/privkey.pem"
 2022-01-28 14:46:17 INFO: plugin "qtun-server" enabled
 2022-01-28 14:46:17 INFO: initializing ciphers... aes-256-ctr
 2022-01-28 14:46:17 INFO: Stream ciphers are insecure, therefore deprecated, and should be almost always avoided.
 2022-01-28 14:46:17 INFO: tcp server listening at 127.0.0.1:35937
 2022-01-28 14:46:17 INFO: running from root user
[2022-01-28T14:46:17Z INFO  qtun_server] loading cert: "/etc/ssl/certs/343.re/fullchain.pem"
[2022-01-28T14:46:17Z INFO  qtun_server] loading key: "/etc/ssl/certs/343.re/privkey.pem"
Error: no private keys found
 2022-01-28 14:46:17 ERROR: plugin service exit unexpectedly
 2022-01-28 14:46:17 INFO: error on terminating the plugin.

It work fine when using RSA certificates:

# This is a RSA certificate
shell> head -n 1 /etc/ssl/certs/dns.343.re/private.key
-----BEGIN RSA PRIVATE KEY-----
shell> ss-libev-server -s 0.0.0.0 -p 12345 -k dnomd343 -m aes-256-ctr --plugin qtun-server --plugin-opts "cert=/etc/ssl/certs/dns.343.re
/certificate.crt;key=/etc/ssl/certs/dns.343.re/private.key"
 2022-01-28 14:48:00 INFO: plugin "qtun-server" enabled
 2022-01-28 14:48:00 INFO: initializing ciphers... aes-256-ctr
 2022-01-28 14:48:00 INFO: Stream ciphers are insecure, therefore deprecated, and should be almost always avoided.
 2022-01-28 14:48:00 INFO: tcp server listening at 127.0.0.1:60863
 2022-01-28 14:48:00 INFO: running from root user
[2022-01-28T14:48:00Z INFO  qtun_server] loading cert: "/etc/ssl/certs/dns.343.re/certificate.crt"
[2022-01-28T14:48:00Z INFO  qtun_server] loading key: "/etc/ssl/certs/dns.343.re/private.key"
listening on 0.0.0.0:12345

Is it wrong with my configuration? Or qtun itself does not support ECC certificates?

[madeye]

It looks rustls doesn't support this format. So, you need to convert them first.

ref: rustls/rustls#245

[dnomd343]

Correct, rustls does not support ECC private keys encoded in SEC1 format, which is the format generated by acme.sh, etc., we have to convert it to PKCS#8 format before it can be used.

Fortunately, openssl can do this work with the follow command:
openssl pkcs8 -topk8 -nocrypt -in YourRawPrivateKey.pem -out NewPrivateKey.pem

In addition, can we consider including the conversion of SEC1 to PKCS#8 in qtun? After all, ECC certificates generated by tools such as acme.sh are not directly supported, and more and more people use ECC certificates for now, which will be more convenient.

[madeye]

IIRC, by default, acme.sh only issue RSA format keys.

So, if you issue some ECC keys explicitly, you'd better convert them by yourself.

Of course, any contribution is welcome. Feel free to open a pull request.

[pexcn]

rustls/rustls#998 seems to already support

[dnomd343]

IIRC, by default, acme.sh only issue RSA format keys.

So, if you issue some ECC keys explicitly, you'd better convert them by yourself.

Of course, any contribution is welcome. Feel free to open a pull request.

Sorry for @madeye not seeing this reply before. I have pushed a PR to enable qtun to support ECC certificates in SEC1 format.