最近兩三個月，斷斷續續的一直在處理CA證書相關的事情。CA證書本質上也是一種加解密，因此就自然而然的涉及到一些加密和解密的技術，這就讓我在瞭解CA的同時，也對加密和解密有了更進一步的認識和理解。
以下便是一個比較雜，但是似乎又有一定關聯性的總結，我分了這樣幾個部分：
1.加密和簽名
2.對稱加密和非對稱加密
3.密鑰、公鑰和私鑰
4.圖解簽名和加密的必要性
5.CA證書轉換
加密和簽名
網絡通信過程中，要保證通信的安全和數據的安全，就需要對交互雙方的身份進行確認，並保證最終業務使用的數據是正確的、未被篡改的、被竊取而無法解析的。
要做到上述要求，就需要使用到加密和簽名，通常交互雙方的身份確認稱作簽名驗籤，而業務數據的安全措施稱爲加密解密。
就目前的理解來說，簽名驗籤實際也是一種加解密。
對稱加密和非對稱加密
加解密一般都需要一個密鑰，如果加密的密鑰和解密的密鑰一樣，則稱作對稱加密。否則，若加密的密鑰和解密的密鑰不一樣，則稱作非對稱加密。
密鑰、公鑰和私鑰
無論公鑰還是私鑰，都是密鑰。
密鑰，理解爲就是密文加密和解密的鑰匙。
公鑰，理解爲公開的密鑰。
私鑰，理解爲私有的密鑰。
需要注意的是，密鑰，不是祕鑰。我剛接觸的時候，就總是把這兩個弄混淆，結果導致幾個概念傻傻分不清。
因爲祕鑰和私鑰似乎是一個意思，所以一旦密鑰理解成祕鑰，就會影響對公鑰和私鑰的理解。
公私鑰一般成對出現，有自己的關聯關係，可以互相加解密，即公鑰加密則私鑰解密，私鑰加密則公鑰解密。
圖解簽名和加密的必要性
最初的網絡數據傳輸使用明文傳輸，那麼通訊過程中完全無法確保數據不被竊取使用和篡改，如下圖：
於是便出現了數據的加密機制，這樣可以確保通信過程中被竊取的數據，在沒有密鑰的情況下難以被解析。即使遭到篡改，接收方也無法解析，而不會繼續進行邏輯處理，如下圖：
但是，這種情況下一旦竊取數據者也擁有了密鑰，那麼就一樣的能夠解析和篡改數據。對稱加密的場景下，密鑰相同，泄露的可能性很大，非對稱加密的場景下，公鑰是公開的，本身就被很多人持有。
那麼數據竊取者有了密鑰之後的情景就大致如下：
因此，在數據加密的基礎上，就又引入了身份驗證，這樣就可以確保數據即使被篡改，也不會被正確驗證和解析，進一步保證了業務安全，如下圖：
以上所述應用到軟件中，實際上是基於http請求，簽名、加密等都發生在實際代碼中。
於是後來有了更進一步的安全措施，即https，在這裏邊就引入了CA證書的概念和技術。
單從通信層面來講，CA證書有根證書和通信證書的區分，實際上是爲了進一步保證服務端和客戶端之間的可信度，進一步保證了通信雙方的身份合法性。
更多ca相關內容可參考我的另兩篇博客：
https://blog.csdn.net/tuzongxun/article/details/88647172
https://blog.csdn.net/tuzongxun/article/details/89217001
CA證書轉換
ca證書有各種格式和不同的文件結尾，很多都是可以相互進行轉換的，也都有不同的使用場景。
例如java通常使用jks文件，安卓通常使用bks文件，而瀏覽器可能使用pfx文件等。
以下是部分轉換的記錄：
根證書鏈pem轉jks
keytool -import -noprompt -file root.pem -keystore root.jks -storepass 123456
證書pfx轉jks
keytool -importkeystore -srckeystore client.pfx -srcstoretype pkcs12 -destkeystore client.jks -deststoretype JKS
證書pfx轉crt和key
openssl pkcs12 -in client.pfx -nodes -out client.pem openssl rsa -in client.pem -out client.key openssl x509 -in client.pem -out client.crt
根證書鏈pem轉cer
openssl x509 -inform pem -in root.pem -outform der -out root.cer
證書jks轉bks需要藉助工具
參見
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0831/3393.html