证书签发大全

valisweet

已于 2022-11-15 21:24:41 修改

阅读量1.2k

点赞数 2

分类专栏：中间件 Golang Kubernetes 文章标签： linux 运维服务器

于 2022-01-13 01:15:56 首次发布

本文链接：https://blog.csdn.net/javahuazaili/article/details/122465557

版权

Kubernetes 同时被 3 个专栏收录

73 篇文章 3 订阅

订阅专栏

Golang

70 篇文章 0 订阅

订阅专栏

中间件

31 篇文章 0 订阅

订阅专栏

博主vx: haitangyijiusu 。很高兴认识你！偶尔带huo，都是精挑细选信得过的产品，欢迎来支持，期待和您相遇！

https://www.cnblogs.com/moonfans/p/3939335.html

0、一些必要的知识点

加密和认证
   加密注重对数据的保护
   认证侧重对身份的辨别以及权限的校验。

加密和解密使用不同的密钥，即非对称加密

原则：
   1、一个公钥对应一个私钥
   2、密钥就是只有自己知道，其它人都不要告知，公钥是让大家都知道。
   3、如果用其中一个钥加密，则只能用另外一个钥来解密。比如，alice用bob的公钥加密的数据，只能用bob的私钥来解密。
   4、如果用其中一个钥能解密，则加密的必然是对应的那个钥来进行的加密。比如。bob用自己的私钥解密了alice发来的数据，则alice加密时必然使用的是bob的公钥。
   5、私钥用于数字签名，公钥验证

基于公钥的加密过程。
假如alice需要发送一个信息给bob。
   1、bob把自己的公钥发给alice
   2、alice用这个公钥对数据加密
   3、将加密后的数据发送给bob
   4、bob用自己的私钥对接收到的数据解密，解密成功后即能看到alice发送的原始数据。

基于公钥的身份认证过程
   身份认证主要是确认一个用户的身份真伪，只要能鉴别一个用户的私钥是正确的，就可以认定这个用户的真伪。
   1、alice用她自己的私人密钥对文件加密，从而对文件进行签名。
   2、alice将这个签过名的数据发送给bob。
   3、bob用alice的公钥进行解密，从而验证签名。解密成功表示这是alice发来的，否则验签失败。

对称密钥加密
   即发送和接收数据的双方必须要使用相同的密钥对数据进行加密和解密运算。对称密钥加密算法主要包括：DES、3DES、IDEA、RC5、RC6等

SSL既用到了非对称加密也用到了对称加密，在建立传输链路时，SSL首先对对称加密的密钥使用公钥进行非对称加密，链路建好后，SSL对要传输的内容进行堆成加密。

单向认证：
   核心是客户端认证服务端
   https://blog.csdn.net/qq_25406669/article/details/80596664

双向认证：
   除客户端认证服务端外，服务端也会对客户端进行认证。（对客户端认证，也就意味着需要客户端也要有自己的公钥和私钥，才能达到双向认证的目的）

单向认证和双向认证，发起方都是客户端，谁是主动方，水才能发起。

私钥可以导出公钥，反之则不行。
公钥加密过的东西,可以用对应的私钥解开.私钥加密过的东西,可以用对应的公钥解开.

签名：
   意味着对某些东西的承诺，当我们生活中纸质签名时，意味着我们对合同内的所有东西都知悉和认同，并愿意为之担起责任。

私钥加密数据时，公钥可以解开，那么现在在私钥加密时，首先对原文内容M计算出其摘要H，再用私钥对其进行加密，并附在原文最后，那么久确保了两个事情：
   1、承诺，即不可抵赖。公钥属于公开信息，假设A在原文后做了签名。意味着A对自己的数据作出承诺。任何一个人都可以拿到A的公钥并解开签名获得摘要，和原文的摘要进行对比，也就知道了数据是否真实。
   2、抗篡改。签名背后就是信息摘要。原文一旦被篡改，摘要也会变化，这样就和签名里的摘要对不上了。

不通场景该如何使用公钥或者私钥加密？
   1、当我想和证书持有人通信时，目的是通信内容只有他一个人解开，因此使用持有人的公钥加密，除了他之外谁也解不开
   2、当我想对某个文件进行签名的时候，别人都应该可以验证这个签名，并且除了我之外，谁也无法冒充我，因此需要使用私钥加密。

证书和公钥私钥的关系

CA证书：
   前面我们说到公钥即身份，但是如何去校验这个身份？这个身份代表了哪些信息？因此证书就诞生了。证书为了实现身份验证的功能，证书包含：
       一个公钥，
       证书主题（TOPIC）
       这个身份持有者的描述，包括：公司组织的相关信息、证书的有效期、签发组织机构、签名使用的算法等等，
       签名（最重要的部分）。
   签名者对这份证书的有效性进行承诺。
   那么谁来签名呢？
   这个签名者必须是一个第三方的权威的证书签发机构。这样的机构称为CA。这样做有以下的好处：
       1、CA在签发证书时会对机构进行审核，确保这个身份的真实性。同时，CA为了保证自己的权威性，不会乱签发证书。
       2、CA的证书通常都会预装在设备里，收到一个声称是CA签发的证书时只要找出证书的签发机构，去CA证书里找出公钥解密签名比对摘要，即可验证证书的真实性。
在客户端发起SSL请求后，服务端会将数字证书发送给客户端，客户端对证书进行校验，并获取用于密钥交换的非对称密钥

数字证书的作用：
   1、身份授权，确保浏览器访问的网站是经过了CA机构验证的可信任网站
   2、分发公钥，每个数字证书都包含了注册者的生成的公钥，在SSL握手时通过certificate消息传输给客户端。

加密的详细过程：
   首先，服务器用非对称加密（RSA）生成公钥和私钥，然后把公钥交给数字证书，并进行包装发给客户端，当公钥到达客户端之后，客户端的TLS首先验证公钥是否有效（颁发机构、公钥有效期、CA数字签名），若存在问题则弹出警告框，提示证书有问题。
   若证书没有问题，则客户端会用对称加密产生一个密钥（此处暂称作S）并用公钥加密后传给服务端，这个密钥就是后续用来通信的密钥。这样服务端接收到这个公钥加密的密钥后就用私钥解密，获得这个密钥S。
   这样，客户端和服务端都获得了这个对称加密的密钥S。从而双方进行安全的通信。

私钥+签名可以反解析出证书

https://www.cnblogs.com/shijingjing07/p/5965792.html
https://www.jianshu.com/p/3688bfd8bdfc
https://blog.csdn.net/ly0303521/article/details/53391741

公钥文件一般以.pem为后缀 （针对众人的一般看做是权限,permission）

私钥文件一般以.key为后缀 （自己的才算钥匙,key）

“保证书”以.csr为后缀，（生成证书之前需要生成责任声明文件（.csr文件），也可以理解成“保证书”表示我这个服务不会为非作歹，不会坑害访问我这个站点的人。。。，Certificate Signing Request。也可以理解成像合作之前的签署协议，CSR一般指企业社会责任。企业社会责任（Corporate social responsibility，简称CSR））

证书文件以.crt为后缀。 CRT 即 certificate的缩写，即证书。

server端的证书的颁发过程是：

ca的签名(ca.crt)+ca的私钥(ca.key)+server端的保证书（server.csr） ==>server端的签名(server.crt)

同理client端的证书颁发过程是：

ca的签名(ca.crt)+ca的私钥(ca.key)+client端的保证书（client.csr） ==>client端的签名(client.crt)

一般会有如下几种钥：

服务端私钥
服务端公钥

客户端私钥
客户端公钥

服务端证书
服务端证书

一、生成钥

# 生成服务器端私钥

openssl genrsa -out server.key 1024

# 生成服务器端公钥

openssl rsa -in server.key -pubout -out server.pem

# 生成客户端私钥

openssl genrsa -out client.key 1024

# 生成客户端公钥

openssl rsa -in client.key -pubout -out client.pem

二、生成CA私钥

# 生成 CA 私钥

openssl genrsa -out ca.key 1024

# X.509 Certificate Signing Request (CSR) Management.

openssl req -new -key ca.key -out ca.csr

# X.509 Certificate Data Management.

openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

注意，这里的 Organization Name (eg, company) [Internet Widgits Pty Ltd]: 后面生成客户端和服务器端证书的时候也需要填写，不要写成一样的！！！可以随意写如：My CA, My Server, My Client。

然后 Common Name (e.g. server FQDN or YOUR name) []: 这一项，是最后可以访问的域名，我这里为了方便测试，写成 localhost，如果是为了给百度的网站生成证书，需要写成 baidu.com。

三、，生成服务器端证书和客户端证书

# 服务器端需要向 CA 机构申请签名证书，在申请签名证书之前依然是创建自己的 CSR 文件

openssl req -new -key server.key -out server.csr

# 向自己的 CA 机构申请证书，签名过程需要 CA 的证书和私钥参与，最终颁发一个带有 CA 签名的证书

openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.crt

# client 端

openssl req -new -key client.key -out client.csr

# client 端到 CA 签名

openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in client.csr -out client.crt

此时，我们的 keys 文件夹下已经有很多文件生成。

四、查看证书过期时间：

echo 证书内容xxxxxxxx |base64 -d
将上面输出的所有内容复制到 11.pem
       cfssl certinfo -cert 11.pem |grep not
           "not_before": "2022-01-10T16:02:27Z",
           "not_after": "2032-01-08T16:02:27Z",

将.pem格式的CA证书转换为.crt格式方式
       openssl x509 -outform der -in your-cert.pem -out your-cert.crt
也可以将（.crt .der 和.cre）转换为pem格式
       openssl x509 -inform der -in certificate.cer -out certificate.pem
校验CA证书的key和crt是否匹配
       openssl x509 -noout -modulus -in your-cert.crt | openssl md5
       openssl x509 -noout -modulus -in your-cert.key | openssl md5
比较验证输出的校验码是否相同即可

五、命令行验证ca证书

1.命令行验证CA证书

[root@k8s-master ssl]# openssl verify -CAfile ca.crt ca.crt
ca.crt: OK

2.如果能从ca.crt和ca.key里拿到公钥，表明ca.key和ca.crt是有效的。

[root@k8s-master ssl]# openssl rsa -pubout -in ca.key
writing RSA key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxMi68xS8hufIa/j/mzpQ
7iP0RdP5N4Rufdl7nehk4l7XjNse4giGYPN6ANS3a10Sh1OYJ17KlnVDsWz8vDV5
QPmcOlYeNfNQD6XmJFVSmM1vNMzW4sU0B0ged1BTqzhJreISpJmUKuJbLqetZW/p
X1I9fUGSVWJpJsR/Rya/jcKdxNkf8CP0wPxP98aj9vBhiwBJSFchkfV+g5P0mn7R
A5cA62JG/VHGiv5b5EiD0LvM1umC6KhJ2q+yh6MFU8G4vaNSmOqwOnXON9tqfqbM
s6XZyb1NW6eugD0H2BfBqD/A/oVpxNEm5GT8VWykQXpswYbBy/Yxoj1Nr+begPPh
tQIDAQAB
-----END PUBLIC KEY-----

[root@k8s-master ssl]# openssl x509 -pubkey -noout -in ca.crt
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxMi68xS8hufIa/j/mzpQ
7iP0RdP5N4Rufdl7nehk4l7XjNse4giGYPN6ANS3a10Sh1OYJ17KlnVDsWz8vDV5
QPmcOlYeNfNQD6XmJFVSmM1vNMzW4sU0B0ged1BTqzhJreISpJmUKuJbLqetZW/p
X1I9fUGSVWJpJsR/Rya/jcKdxNkf8CP0wPxP98aj9vBhiwBJSFchkfV+g5P0mn7R
A5cA62JG/VHGiv5b5EiD0LvM1umC6KhJ2q+yh6MFU8G4vaNSmOqwOnXON9tqfqbM
s6XZyb1NW6eugD0H2BfBqD/A/oVpxNEm5GT8VWykQXpswYbBy/Yxoj1Nr+begPPh
tQIDAQAB
-----END PUBLIC KEY-----