跟第三方支付之间通信通常采用的https，而https用到了SSL，java中一般都是SSLSocket完成通信的。本来之前一直用得好好的，最近突然在服务器上，报了以下错误：

java.security.ProviderException: java.security.KeyException

这个错误在网上找了下，竟然没有相关资料。没办法，只能自己跟踪代码，最后通过跟踪代码，发现在sslsock.startHandshake();时报错了。了解SSL的一看就知道这个异常发生在SSL三次握手上，天哪，这可以是JDK内部的错误啊，要改也改不了啊。其实吧，这已经是第二次遇到这个错误了，之前也遇到过一次，那次因为要发生产环境，没有过多时间分析这个问题，初步定为也是JDK的问题，但不知道出现在JDK什么地方，后来把JDK做了降级就好了。（因为我们之前也用过同一个第三方支付，而另一台服务器上是好的，通过对比之后发现，除了JDK不一样，其他都一样，不行的那台服务器就是JDK版本高了，我记得好像是jdk1.7_85，而没有问题的那台服务器是jdk1.7_71，后来换成jdk1.7_71果然好了，不过一直不知道深层次的原因。）

于是把关键字sslsock.startHandshake()  再加java.security.KeyException，在网上又搜了一下，终于折腾了老半天，在一个论坛里找到了点眉目，大概意思是操作系统的问题。我们用的是Cent OS，那个帖子上说的是乌班图系统的一个BUG。然后再深究看到底是什么问题，最后发现，原来不是JDK的问题，而是nss包的问题。

真正的原因是Open JDK在使用SSL时，支持哪些协议和加密算法是拿的之前Oracle的协议列表。而在真正使用协议和算法的时候（SSL的三次握手）使用的却是nss包里的provider，这就导致了JDK在通知服务器时说他支持这些算法列表，等服务器返回需要真正用的时候nss里没有这个算法，就会报这个异常。

要解决这个问题有两种方式，第一种就是我之前把JDK降级处理，因为老版本的JDK支持的算法列表比较少，可能跟nss里支持的一致，就没有问题。第二种就是把nss包升级，一般JDK1.7的nss升级到3.16.1以上就没问题了。

通常遇到这个异常时，查下nss版本，升级下就可以了。

查看nss版本:rpm -q nss

升级nss:yum update -y nss

对了，这个问题还就是Open JDK才有的，因为Open JDK依赖nss，而Oracle JDK因为有自己的EC，不依赖nss，所以没有这个问题。因为现在android用的都是Open JDK，服务端也用Open JDK统一起来能避免不少问题。而且Open JDK也是未来的趋势，还是建议使用的。对了，貌似在Open JDK 1.8里面这个BUG已经解决了。