SSL error with a ecc secp521r1 key about openbsd HOT 3 CLOSED

This is due to the fact that secp521r1 is not one of the default signature algorithms or SIGALGS, which causes the TLS session negotiation to fail (the current defaults are X25519, secp256r1 and secp384r1). Using the -named_curve option on s_server and the -groups option on s_client will allow this key to work:

$ openssl s_server -accept 3443 -cert crt.crt -key key.key -named_curve secp521r1
openssl s_client -state -nbio -CAfile crt.crt -connect localhost:3443 -groups secp521r1

(thanks for the detailed report)

from openbsd.

Yes the options does work with openssl s_server and s_client. So what about other programs linked with libssl.so that also failed with secp521r1 ecc key such as curl, python, ruby, etc...?
And, since secp521r1 is written out of default, is there some way to enable it optionally? or I should simply drop it and treat it as insecure and never trust it anymore?

from openbsd.

EC curves can be enabled/disabled via the SSL_set1_groups_list(3) (or SSL_set1_curves_list(3)) API - how this is exposed to the user depends on the application or programming language in question.

I'm not aware of any specific issues with secp521r1, however it is unlikely to provide significant advantages over secp384r1 and secp256r1. In many cases X25519 is going to be preferable (see https://safecurves.cr.yp.to/ for some further reading). Additionally, BoringSSL does not enable secp521r1 by default and Chrome does not support it...

from openbsd.