CA证书01-基础知识-PKI、CA、证书、密钥对

飞奔的炮台

最近需要自建CA制作证书，之前也有使用ca，原理比较模糊。这次详细研究了下，记录下
简单概述下：
证书：包含公钥，证书本身的一些基本信息，CA的数字签名
证书请求：请求包含证书需要的信息和来自私钥的数字签名
客户端、服务器：信任CA证书，CA公钥解密数字签名，验证证书是否由CA颁发

• PKI：公钥基础设施。这描述了 CA、密钥对、请求和证书之间的文件和关联的集合。
  
• CA：证书颁发机构。这是 PKI 根目录下的“主证书”。
  
• 证书：证书。证书是由 CA 签署的请求。该证书包含公钥、描述证书本身的一些详细信息以及来自 CA 的数字签名。
  
• request：证书请求（可选'req'。）这是对证书的请求，然后将其发送到 CA 进行签名。请求包含所需的证书信息以及来自私钥的数字签名。
  
• keypair：密钥对是非对称加密的密钥对。这些密钥分为两部分：公钥和私钥。公钥包含在请求和证书中。
  

密钥对和请求
单个终端实体不需要完整的 CA 设置，只需要创建一个密钥对和相关的证书请求。除此实体外，不会在任何地方使用私钥，并且绝不能离开该系统。使用强pass保护这个私钥是明智的，因为如果丢失或被盗，私钥持有者可以作为证书持有者建立连接。
生成密钥对后，将创建证书请求并 以数字方式 使用私钥签名。此请求将发送到 CA 进行签名，并返回签名证书。

请求如何成为证书
CA 签署证书请求后，会生成一个签署的证书。在这一步中，CA的私钥用于以数字方式 签署实体的公钥，以便任何信任 CA 证书的系统都可以 含蓄地信任新颁发的证书。然后将此签名证书发送回请求实体。颁发的证书不是安全敏感的，可以通过明文传输方法发送。

验证已颁发的证书
在 2 个实体创建密钥对，向 CA 发送他们的请求，并收到他们签名的证书和 CA 自己的证书的副本后，他们可以相互 认证与另一个。这个过程不需要两个实体之前直接交换过任何类型的安全信息。
在 TLS 期间 握手连接的每一端都向远程端提供自己的证书链。每一方根据自己的 CA 证书副本检查收到的证书的有效性。通过信任 CA 根证书，他们正在与之交谈的对等方可以是已认证.
远程端通过使用自己的私钥对一些数据进行签名来证明它“确实是”由证书标识的实体。只有私钥的持有者才能这样做，允许远程端验证真实性 所连接的系统。