我有一个openjdk 7u21-2.3.9-5的库存安装，包含在Linux Mint Debian Edition（jessie / sid）201403中。
我试图编写java代码来建立使用Elliptic Curve密钥进行相互身份验证的SSL / TLS连接。它没有用。
更新： 自从发布此问题以来，我已经成功地通过对服务器和客户端密钥使用secp256r1曲线（而不是secp256k1）建立安全连接。但是我离开这个问题主要是因为我最初写的，因为我仍然对这个问题的答案感兴趣。我特别注意到the security of the secp256r1 curve has been questioned。
在搜索互联网寻求帮助时，我的注意力被调用到java.security文件中列出的倒数第二个提供商：
#security.provider.9=sun.security.ec.SunEC
这是为什么？为什么要注释掉？
我尝试过使用基于secp256k1和secp256r1曲线的SSL（TLS）客户端密钥。我也尝试过添加bouncycastle作为提供商。使用secp256k1的服务器证书，即使有可用的bouncycastle提供商，我也无法建立连接;另一方面，如果服务器和客户端密钥都基于secp256r1曲线，那么我可以建立安全连接。
到目前为止，我的理解是有一个SunEC加密提供程序支持所有EC曲线，但不包含在OpenJDK中，如果我能找到并安装正确的java jar文件和二进制共享二进制库，那么我可以使用该提供程序，但是它与包含的rt.jar文件之间存在一些不兼容性。
此外，据我所知，OpenJDK附带的SunPKCS11提供程序处理EC曲线的子集，包括secp256r1，但不包括secp256k1。如果bouncycastle可用，那么当尝试使用secp256k1曲线作为客户端密钥时，它似乎就会启动，而不是服务器密钥。我对理解的准确性没有信心，因为它基于来自线索评论和其他非权威来源的信息。
我还对以下事实感到困惑：调用方法sun.security.ec.NamedCurve.getECParameterSpec("secp256k1")会返回EC参数规范，表明我的JDK 知道该曲线。所以我很困惑为什么它不能使用基于该曲线的键来处理SSL证书。
此时我能够建立安全连接，但只能使用某些EC曲线。我希望可以选择使用更多曲线，并且通常非常好奇为什么在分布式java.security文件中指定了注释掉的提供程序。那是我的问题：为什么会这样;我怎么用呢？