原创：打码日记（微信公众号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网络异样场景剖析
字符编码解惑