最近碰到的一些 SSL 問題記錄

最近碰到一些 SSL 的小問題，特記錄下。 

咱們有個 Java 實現的 SSL TCP 服務端，爲客戶端（PC、Android 和 iOS）提供 SSL 接入鏈接服務。最近有用戶反饋其手機上 App 不能正常鏈接登陸，別人手機上均可以。通過單獨回訪調查該用戶使用的手機操做系統是 Android 6.0，經搜索瞭解了 Android 6.0 以後 Google 使用了自家的 BoringSSL 替換了原來的 OpenSSL，懷疑是這裏在搗鬼。 

繼續搜索相似問題解決方案，在參考[1] 中找到答案: 

 SSL/TLS握手過程當中，假如選中了諸如 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 這樣使用 deffie-hellman 密鑰的 cipher，那麼在 deffie-hellman 密鑰交換過程當中會使用的一個P參數（prime number），服務器側提供的 P 參數在 JDK8 以前都只用了 768bit 的長度，小於 1024bit 存在安全漏洞可致使 logjam attack，會被最新本版的瀏覽器和 BoringSSL 拒絕。 

明瞭了緣由後咱們只好把 JDK 從 6 升級到了 8，順利解決 Android6.0 SSL 握手失敗問題。但解決完這個後，沒多久又發現 APNS iOS 推送又不可用了，和蘋果推送服務器創建 SSL 鏈接失敗，沒法推送消息。惟一的變化就是升級到了 JDK8 天然就將懷疑目標對準了 JDK8。 

繼續 Google 一把找了同類受害者，他已經搞明白了緣由，見參考[2] 

The problem was the exported keystore (in PKCS12 format) contained the private key as well as the production certificate and the development certificate for push notifications. Java can use keystores in the PKCS12 format. But Java 6 and Java 8 did not read-in the keystore the same way. It looks like Java 6 read in the production certificate for the private key and Java 8 read in the development certificate. 

解決辦法也很簡單，先用 JDK6 提供的 keytool 將 .p12 格式的證書轉換爲 .jks 格式。再用 JDK8 提供的 keytool 將剛生成的 .jks 證書轉換爲 .p12 格式。轉換命令以下： 

.p12 -> .jks 

/JDK6/keytool -importkeystore -destkeystore apns.jks -srckeystore apns_jdk6.p12 -srcstoretype PKCS12 

 .jks -> .p12 

/JDK8/keytool -importkeystore -srckeystore apns.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore apns_jdk8.p12 

 參考 

[1] liuxian233. Android 6.0 HTTPS鏈接ssl3_get_server_key_exchange:BAD_DH_P_LENGTH錯誤問題 

[2] szediwy. Apple Push Notification with Java 

[3] ASHISH PARAB. APPLE PUSH NOTIFICATION SERVICE CERTIFICATE ISSUE WITH JDK 7