本文以银行数字证书作为范例
1. 银行首先要自己创建一个数字证书，证书中包含的信息有本证书采用的是何种加密算法、公钥、发行者、有效期以及其他属性，然后提交给权威的CA机构对数字证书进行签名。为什么要CA签名？因为只有权威CA认证进行签名才可信呀，你自己给自己签名，既无担保也不可信。而CA的权威性是与生俱来的，它无需再认证，无论是浏览器还是JDK，关于CA的根证书都是默认就存在的，并且在使用的时候会直接加载。
2. CA把签名认证过的数字证书返回给银行，这个证书里面就多了一个CA的数字签名，这样CA会承担一个风险担保的责任，当然，银行为了获得这份签名证书，需要向CA提供签名费用，类似保险金一样。银行收到这份由CA签名后的数字证书以后，就把它连同该证书所对应的私钥一起，存放在本地的密钥库中。
银行准备工作做完以后，就将可以把服务器配置成支持SSL/TLS协议的访问方式，比如https，然后静静的等待接收客户端的服务请求。
接下来就是客户端和银行之间的一次https交易的全过程了：
3. 客户端发起以https开头的服务请求，告诉银行，我这里可以使用https协议访问你哦。
4. 银行收到服务请求后，把密钥库中的服务端证书取出来，然后告诉客户端，你拿去，看看我的数字证书条款你认可不认可？
5. 客户端收到银行发送来的数字证书一看，呀，还有CA的数字签名，高大上啊！不行，我得检查一下这份证书签名到底可靠不可靠，会不会是伪造的呢？所以客户端又把这张证书发送到CA那里进行数字签名的验证。
6. CA对客户端发过来的数字证书经过一番打量，验明正身后，告诉客户端，没错，这个数字证书是我签名的，没问题，No problem。
再往下，客户端和银行就开始就SSL/TLS协议的细节进行更为深入的双边探讨了，比如本次会话要采用什么对称加密算法啦，加密通道建成后使用什么样的共同密钥啦!这个过程比较复杂，！@#￥%……&*（），一两句话是解释不清的，一般人也无需深入了解，早有大牛将其封装好了。
只要知道，最后它们俩达成了协议，双方一致同意要采用同一份密钥，使用对称加密算法对通讯隧道中的传输数据进行加解密操作。
另外，每一次会话所得到的，用于对称加密算法的共同密钥也是不同的，随机产生，确保了数据安全性，须知银行数据可就是账户信息，那就是钱呀！
原文地址：http://blog.csdn.net/robinsone/article/details/45244645
