Join GitHub today
Using a Let's Encrypt ECC cert for TLS fails. The NGBGet server process listens on the TLS port, but browsers show an ERR_SSL_VERSION_OR_CIPHER_MISMATCH error when negotiating the connection.
Openssl doesn't ever see the server certificate in the negotiation:
Are you sure you are connecting to correct port?
Can you please verify that when you use a self-signed certificate from http://www.selfsignedcertificate.com/ it works? This is to ensure the problem occurs only with let's encrypt certificates and is not a general one.
Once verified I would need a certificate to test with. Can you provide me with one? That would be a great help.
More info about your system may help too:
Yes, port is correct.
Platform: QNap - installed first from QNap package, since upgraded using the upgrade option wishing nzbget to the current beta build.
The issue actually only occurs when using an ECC cert from Let's Encrypt. RSA certificates (just like self-signed) work fine. You can create certs directly from Let's Encrypt using a client like acme.sh to test with.
RSA cert (requires port 80 open): acme.sh --issue --standalone -d example.com -d www.example.com -d cp.example.com
I wasn't able to figure out how to enable debugging to see if anything is thrown on the server side error wise. If you can share how to enable, I can collect that information as well to trace what might be failing on the listener.
This only solves the problem when using the prime256v1 algorithm.
If you create a certificate using the secp384p1 (and presumably others) key algorithm you will get the same ERR_SSL_VERSION_OR_CIPHER_MISMATCH style error.
As a test I substituted NID_X9_62_prime256v1 for NID_secp384r1 at
A proper fix would obviously handle secp384r1 and the other permissible algorithms.