数字证书的生成方式：

第一步，密钥生成。有两种方法，一是主体可以用某个软件生成的公钥/私钥对，主体要使生成的私钥保密，然后把公钥和其他信息与身份证明发送给注册机构。二是注册机构也可以为主体生成密钥对，可能用户不知道生成密钥对的技术，或特定情况要求注册机构集中生成和发布所有密钥，便于执行安全策略和密钥管理。
第二步，注册。这一步只在第一步由用户生成密钥对时才需要。用户要向注册机构发送公钥和相关注册信息（如主体名）以及关于自己的所有证明材料。
第三步，验证。注册过程完成后，注册机构要验证用户的材料，这个验证分为两个方面。首先，RA要验证用户材料，如提供的证据，保证它们可以接受。然后的检查是保证请求证书的用户持有向A的证书请求中发送的公钥所对应的私钥。
第四步，证书生成。假设上述所有步骤成功，则RA把用户的所有细节传递给证书机构。证书机构进行必要的验证，并对用户生成数字证书。

演变方式：
 

前言：

说到https应该已经很熟悉了，他与http有何区别呢? 答：https更安全，因为使用了tls协议，即有证书认证的操作，具体是一种怎样的交互呢，让我们细细道来。

0，数字证书以及网络传输加密

     假设，有两个人，一个叫 小起，一个叫 小终，小起想给小终发送数据，可是怕别人截取，篡改等等一些不安全的行为，于是经历了如下的演变过程，直到最后得到了最完美的加密过程。

 stage1: 对称加密

          小起     ----------将数据加密，并带着能解密的钥匙，一起交给小终   -----------> 小终

          问题：传输的过程中，钥匙可能被盗

 stage2：非对称加密

          小终：自己有一个秘钥对，公钥：对外公开；    私钥：自己保留；    由公钥加密的数据只能由私钥解密，由私钥加密的内容只能由公钥解密

          小起     ----------将数据用小终的公钥加密，交给小终   -----------> 小终（用小终自己的私钥解密）

          问题：传输的过程中，有人将数据截获，搞一堆烂七八糟的内容重新用小终的公钥加密，再发给小终。

 stage2进阶：签名技术的应用

　　    利用hash算法不可逆的特性，将正文数据进行hash计算得到摘要，当小终收到正文后同样hash计算，如果二者相同说明数据是完整的。
　　　同时，小起还要告诉小终，这个摘要是我计算的，可不是别人计算的的。

           小起 -----------------1)就数据用小终的公钥加密； -------------------------------------------------------------------> 小终（用自己的公钥解密数据，用小起的公钥解密签名）
                                        2)将数据用hash算法计算出摘要，并用小起的私钥对摘要进行加密（签名)

          问题：有人冒充是小起给小终发数据

 stage3：数字证书                  

          前面说了公钥/私钥都是自己家搞出来的东西，就算是被仿造了也不知道，于是将公钥"贴在第三方出具的正式文件上"（我们所说的签发数字证书）。这样就显得有保障，因为这个正式文件上可是有第三方盖章的。但同样还要能够识别这个"章"是真正权威机构的。具体原理是：

          小起，小终    <-----------从ca那里获取两样：根证书（“印章”图样），公钥（数字证书)私钥对---------CA中心（证书颁发机构）

          小起 (用根证书校验小终的数字证书)   <---------交换数字证书 -----------> 小终（用根证书校验小起的数字证书）

 整合：对称加密结合非对称加密

　　   考虑到效率问题，真正的业务数据是用对称加密算法加密的。所以综合以后，过程是这样的：
　　   通过stage3，我们现在互相已经有了对方准确的公钥，然后通过stage2的数据交换协商出对称加密秘钥自己保存好，再用stage1的对称加密算法（此时不需要携带解密秘钥）加密数据

          小起   --------- 用对称加密算法加密的数据-----------> 小终