最近两三个月，断断续续的一直在处理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
