0%

CA证书和自签名证书

发表于 更新于 分类于

在kubernetes集群的搭建过程中，需要使用许多证书，例如运行kube-apiserver需要指定客户端CA证书、服务端证书和私钥，而客户端组件如kubectl需要指定自己的证书、私钥以及服务端CA证书。

1
kube-apiserver --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file=/etc/kubernetes/ssl/ca.pem

kube-controller-manager组件还需要指定CA私钥，用于为kubelet签名证书。

1
kube-controller-manager --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.pem --cluster-signing-key-file=/etc/kubernetes/ssl/ca-key.pem

这些文件在TLS认证过程中发挥什么作用，关键需要理解CA证书以及自签名证书。

对称加密和非对称加密

  • 对称加密：如AES，速度快，但密钥管理困难
  • 非对称加密：如RSA，速度慢，两种用途：(1)加密传输过程：公钥加密，私钥解密；(2)签名过程：私钥加密，公钥解密
  • 一般传输数据用对称加密，对对称密钥的传输用非对称加密，例如TLS协议握手阶段通过非对称加密交换一些信息，从而生成对称密钥，后续数据传输就用此密钥。

签名和证书

  1. 签名的作用

    • 确保信息不被篡改
    • 确保信息来自发布者

  2. 签名的原理

    对信息HASH后得到摘要，然后用私钥加密得到签名，接收方能够用公钥解密说明是对方发送的，然后再次对信息HASH得到相同的摘要值说明信息没有被修改。

  3. 证书

    简单来说就是对公钥签名，上述签名过程的漏洞在于接收方持有的公钥如果被人替换，就可以被假冒者回复信息，解决的办法是对公钥进行认证，也就是通过CA密钥对公钥进行加密得到证书，接收人不直接拿到公钥，而是证书，接收人通过CA的公钥可以从证书中验证得到发送人的公钥。只要CA私钥不泄露，就不可能被其他人冒充。

CA证书

CA是一个机构，专门为其他人签发证书，这个证书保存其他人的公钥，确保了公钥的来源且没有被篡改。

CA本身有自己的公私钥对，私钥用于签发其他证书，公钥用于验证证书，CA公钥同样需要保护，这就是CA证书。

那么CA证书是谁签发呢，从签名的原理来看，必然存在CA自己给自己签名，这就是根CA证书。

根CA是非常宝贵的，通常出于安全的考虑会签发一些中间CA证书，然后由中间CA签发最终用户证书，这样就构成了一个信任链。接收者信任某个CA证书，那么由此CA签发的证书就都被信任。

公信的根CA全球只有有限的一些，它们通过第三方机构审计，具有权威性和公正性，通常操作系统或浏览器已经内置安装，由这些根CA签发的证书都会被信任。

用户也可以自行安装信任的证书，其风险需要用户自己承担，一定要确保证书来源可靠。

自签名证书

所以根证书一定是自签名的。

公信的CA是非常宝贵的资源，从其申请证书是需要付费的，并且有些场景并不需要公信的证书，这时就会自建CA，需要用到自签名，下面通过两张图说明自签名证书和非自签名证书的区别。

  • 自签名证书

1571995218957

  • 非自签名证书

1571995306431

kubernetes集群就是采用自建的CA，用自建CA签发各组件交互需要的证书，CA证书起到验证对端身份的作用，交互的双方都需要知道对方的CA证书。kube-controller-manager需要为kubelete签发证书，所以它还需要CA的私钥。

-------------本文结束感谢您的阅读-------------