qtun doesn't work when using ECC certificate
dnomd343 opened this issue · 5 comments
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?
It looks rustls
doesn't support this format. So, you need to convert them first.
ref: rustls/rustls#245
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.
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.
rustls/rustls#998 seems to already support
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.