发现问题原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。
在上周一个将要下班的夜晚，测试突然和我打招呼，说IOS推送的修复更新上线后存在问题，后台报错。
连忙跑到测试那里看报错详情，报错如下：
看到这个报错后，在网上搜索了一下，这种错误一般都是因为客户端不信任服务端SSL证书导致的，回想工作以来，好像遇到这种问题好多次了，只要将证书导入一下就好了。
由于不能冒然在线上修改解决问题，于是获取推送相关信息(如：设备token)后，到自己电脑上去测试，看是否能重现问题。
啪啦啪啦，代码修改完毕，点运行坐等错误出现。
5秒钟过后，发现推送消息发送成功了，没有出现报错，有点懵逼！心里想，代码都是完全一样的啊，怎么线上报错，我这却是好的呢？？？
纠结了一会，于是开始静下心来分析：
- 代码肯定是一样的，应该不是表面上的代码原因。
- 其次推送设备也是一样的，应该也不是手机问题。
- 那么。。。
就在没有头绪之际，我又扫了一眼工程目录，发现了jdk8，但我们线上系统使用的是jdk7啊。
于是我将自己工程的jdk8换成jdk7试一下，同样的报错终于出现了！
那为什么jdk8没问题，jdk7却报错呢？？？
寻找原因围绕着网上的说法和之前的经验，这hand_failure错误应该是SSL/TLS握手过程中不信任服务端证书导致的，那办法很简单，去苹果官网找到苹果服务端提供的证书，导入到java的证书信任库cacert文件中即可。
于是，下载了证书文件GeoTrust_Global__CA.cer，并用jdk自带的keytool工具将证书导入到cacert文件中，如下：
如上，导入过程中，发现提示已经有这个证书了，当时没想那么多，再导一次试试吧！
导入后，再次运行代码，结果还是报错！
心里又慌乱起来，没招了，于是又百度/google去了，但搜索出来的结论几乎都是证书信任问题，和自己的招式一样！
同时，也了解了一下SSL/TLS协议相关知识，大致握手过程如下：
详细如下：
-
客户端发送clientHello消息，告诉服务端我使用的TLS版本与加密套件等。
-
服务器返回serverHello消息，告诉自己选择哪个TLS协议版本与加密套件等。
-
服务器发送Certification消息，将自己的数字证书（包括服务器名称、CA和公钥）作为消息内容发给客户端。
-
客户端Certificate verify校验服务器的数字证书的有效性。
-
客户端Change cipher spec选择加密套件并生成会话密钥（客户端与服务器之间后续的数据传输将使用此会话密钥）。
-
客户端、服务器之间发送加密数据。
另外，jvm有一个-Djavax.net.debug=SSL的参数，可以把SSL/TLS的握手过程都在控制台通过日志显示出来，如下：
Ok，既然知道了握手过程，那就把SSL/TLS的日志显示出来看一下吧，看看是什么阶段出现的问题，如下：
这说明GeoTrust_Global.cer证书确实已经添加到信任库中了，而详细的SSL日志如下：
如上图，报错发生在clientHello发送之后，在读服务端返回的serverHello消息时，却读到的是Alert:handshake_failure警告信息，然后SSL握手就中断了，就好像你在和服务器打招呼，然后服务器回复了一个滚蛋一样！
百思不得其解？
准备放弃一会，我看到测试走了过来。
测试：“问题解决的怎么样了，啥情况啊”
我：“还不知道，本来以为很简单，实际上并没有，jdk8可以，7不行”
测试：“好吧”
我：”要不升级jdk8吧“
测试：”能行吗“
我：”......能行，jdk兼容性都很好，而且其它系统都已经升级过了，这个系统本来也计划要升，问题不大“
测试：”......好的“
于是，测试去升级jdk8了，本来我应该站在测试身后等待问题被解决，但我还是想在这期间查一查根本原因，于是又琢磨了起来。
发现真相回想起，这个系统以前本来是jdk6，就是因为苹果强制开发者必须使用Https，且需要TLSv1.2版本，而jdk7才开始支持TLSv1.2，所以这个系统才升级到jdk7，那现在这个报错会不会...
于是，我赶紧使用TLSv1.2试试，添加jvm参数-Dhttps.protocols=TLSv1.2即可强制https使用TLSv1.2版本协议，如下：
加完后再次运行，报错依旧，那还有那里可能会有问题呢？
我突然灵光一闪，使用jdk7运行一次，再使用jdk8运行一次，将两次的SSL日志对比一下，看看哪里不一样，说不定能找到线索！
于是我马上试运行并对比两次SSL日志，发现两次SSL日志中TLS协议使用的加密套件不同，如下图：
jdk7的调试信息如下 ：
jdk8的调试信息如下：
jdk8的TLS握手在服务端ServerHello之后，选择的加密套件是TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384，而jdk7中可供选择的加密套件中没有TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384。
问题差不多清晰了，应该是jdk7中的加密套件，苹果服务器觉得太老不安全，都不支持了，那么如果我使用jdk8，并将加密套件强制为jdk7中的加密套件呢，应该也是会报错的！
于是，我还是使用jdk8，并添加了jvm参数-Dhttps.cipherSuites=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA，以强制jdk8使用jdk7的加密套件，如下：
再次运行后，果然报错了！所以应该是jdk8支持了一些新的加密套件，而苹果服务端只认这些新的加密套件导致的。
于是，我去jdk官网，查了一下jdk8的新增特性，发现TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384中AES加密算法的GCM模式在jdk8中才支持，如下：
至此，问题原因全部搞清楚了，测试升级jdk8后也报告推送正常，此时已是10点多，两人写写日报赶紧回家去了......
往期内容密码学入门
时区的坑，不想再踩了！
常见的Socket网络异常场景分析
字符编码解惑