shadowsocks/qtun

qtun doesn't work when using ECC certificate

dnomd343 opened this issue · 5 comments

dnomd343 commented

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 commented

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

ref: rustls/rustls#245

dnomd343 commented

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.

  • 👍1
madeye commented

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 commented

rustls/rustls#998 seems to already support

dnomd343 commented

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.

  • 👍1