Kubernetes证书类型和适用场景
Posted 琦彦
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kubernetes证书类型和适用场景相关的知识,希望对你有一定的参考价值。
TLS/SSL证书
1. 数字证书与 PKI 公钥基础架构
我们在前面已经学习了「对称密码算法」与「非对称密码算法」两个密码学体系,这里做个简单的总结。
- 对称密码算法(如 AES/ChaCha20): 计算速度快、安全强度高,但是缺乏安全交换密钥的手段、密钥的保存和管理也很困难。
- 非对称密码算法(如 RSA/ECC): 计算速度慢,但是它解决了上述对称密码算法最大的两个缺陷,一是给出了安全的密钥交换算法 DHE/ECDHE,二是它的公钥是可公开的,这降低了密钥的保存与管理难度。
但是非对称密码算法仍然存在一些问题:
- 公钥该如何分发
- 比如 Alice 跟 Bob 交换公钥时,如何确定收到的确实是对方的公钥,也就是说如何确认公钥的真实性、完整性、认证其来源身份?
- DH/ECDH 密钥交换协议可以防范嗅探攻击(窃听),但是无法抵挡中间人攻击(中继)。
- 如果 Alice 的私钥泄漏了,她该如何作废自己旧的公钥?
数字证书与公钥基础架构就是为了解决上述问题而设计的。
首先简单介绍下公钥基础架构(Public Key Infrastructure),它是一组由硬件、软件、参与者、管理政策与流程组成的基础架构,其目的在于创造、管理、分配、使用、存储以及撤销数字证书。 PKI 是一个总称,而并非指单独的某一个规范或标准,因此显然数字证书的规范(X.509)、存储格式(PKCS系列标准、DER、PEM)、TLS 协议等都是 PKI 的一部分。
我们下面从公钥证书开始逐步介绍 PKI 中的各种概念及架构。
1.1 公钥证书
前面我们介绍了公钥密码系统存在的一个问题是「在分发公钥时,难以确认公钥的真实性、完整性及其来源身份」。 PKI 通过「数字证书」+「证书认证机构」来解决这个问题,下面先简单介绍下「数字证书」。
数字证书指的其实就是公钥证书(也可直接简称为证书)。 在现代网络通讯中通行的公钥证书标准名为 X.509 v3, 由 RFC5280 定义。 X.509 v3 格式被广泛应用在 TLS/SSL 等众多加密通讯协议中,它规定公钥证书应该包含如下内容:
-
证书
-
序列号(Serial Number): 用以识别每一张证书,在作废证书的时候会用到它
-
版本: 证书的规范版本
-
公钥(Public Key): 我们的核心目的就是分发公钥,因此显然要把公钥放在证书里面
-
公钥指纹: 即公钥的 Hash 值,当前大部分证书都使用 SHA256 计算此指纹
-
公钥用途(Key Usage + Extended Key Usage): 记录了此证书可用于哪些用途——数字签名、身份认证等
-
主体
(Subject): 即姓名、组织、邮箱、地址等证书拥有者的个人信息。
- 有了这个我们就能确认证书的拥有者了
-
证书有效期的开始时间、结束时间
(Not Before + Not After): 为了确保安全性,每个证书都会记录一个自身的有效期
- 证书一旦签发并公开,随着科技的发展、时间的推移,其公钥的安全性会慢慢减弱
- 因此每个证书都应该包含一个合理的有效期,证书的拥有者应该在有效期截止前更换自身的证书以确保安全性
-
签发者(Issuer): 签发此证书的「签发者」信息
-
其他拓展信息
-
-
数字签名
(Signature): 我们还需要对上面整个证书计算一个数字签名,来确保这些数据的真实性、完整性,确保证书未被恶意篡改/伪造
- 此数字签名由「证书签发者(Issuer)」使用其私钥+证书内容计算得出
-
数字签名算法(Signature Algorithm): 证书所使用的签名算法,常用的有
RSA-SHA-256
与ECDSA-SHA-256
每个证书都有唯一的 ID,这样在私钥泄漏的情况下,我们可以通过公钥基础设施的 OCSP(Online Certificate Status Protocol)协议吊销某个证书。 吊销证书的操作还是比较罕见的,毕竟私钥泄漏并不容易遇到,因此这里就略过不提了,有需要的可以自行搜索。
1.2 证书的名词解释
证书相关的编码格式
同样的 X.509 证书,可能有不同的编码格式,目前有以下两种编码格式。
1、PEM - Privacy Enhanced Mail
打开看文本格式,以“-----BEGIN…”开头,“-----END…”结尾,内容是 BASE64 编码。
查看 PEM 格式证书的信息:
openssl x509 -in certificate.pem -text -noout
。Apache 和 UNIX 服务器偏向于使用这种编码格式。
2、DER - Distinguished Encoding Rules
打开看是二进制格式,不可读。
查看 DER 格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout 。
Java 和 Windows 服务器偏向于使用这种编码格式。
证书相关的文件扩展名
这是比较误导人的地方,虽然我们已经知道有 PEM 和 DER 这两种编码格式,但文件扩展名并不一定就叫“PEM”或者“DER”,常见的扩展名除了 PEM 和 DER 还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式。
1、CRT
CRT 应该是 certificate 的三个字母,其实还是证书的意思。常见于 UNIX 系统,有可能是 PEM 编码,也有可能是 DER 编码,大多数应该是 PEM 编码,相信你已经知道怎么辨别。
2、CER
还是 certificate,还是证书。常见于 Windows 系统,同样的可能是 PEM 编码,也可能是 DER 编码,大多数应该是 DER 编码。
存放证书文件可以是二进制编码或者BASE64编码
3、KEY
通常用来存放一个公钥或者私钥,并非 X.509 证书。编码同样的,可能是 PEM,也可能是 DER。
查看 KEY 的办法:openssl rsa -in mykey.key -text -noout
。
如果是 DER 格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout **-inform der**
。
4、CSR
Certificate Signing Request,即证书签名请求
。证书请求文件,这个并不是证书,而是向证书颁发机构获得签名证书的申请文件,其核心内容是一个公钥(当然还附带了一些别的信息)。在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好。
查看的办法:openssl req -noout -text -in my.csr
(如果是 DER 格式的话照旧加上 -inform der,这里不写了)。
5、PFX/P12
包含所有私钥、公钥和证书。其以二进制格式存储,也称为 PFX 文件,在windows中可以直接导入到密钥区,密钥库和私钥用相同密码进行保护
predecessor of PKCS#12,对 unix 服务器来说,一般 CRT 和 KEY 是分开存放在不同文件中的,但 Windows 的 IIS 则将它们存在一个 PFX 文件中,(因此这个文件包含了证书及私钥)这样会不会不安全?应该不会,PFX 通常会有一个“提取密码”,你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX 使用的时 DER 编码,如何把 PFX 转换为 PEM 编码?
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
这个时候会提示你输入提取代码,for-iis.pem 就是可读的文本。
生成 pfx 的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
其中 CACert.crt 是 CA(权威证书颁发机构)的根证书,有的话也通过 -certfile 参数一起带进去。这么看来,PFX 其实是个证书密钥库。
1.3 SSL 证书主流格式说明
SSL 及 TLS(新版SSL)统称 SSL 证书(又称 CA 证书、数字证书),用于数据传输过程的加密。
本质上 SSL 证书是一个 X.509 证书,是定义证书数据结构的标准。在 X.509 标准下,包含 Base64 ASCII 文本与二进制两种文件储存方式,根据使用的格式和编码,证书文件具有不同的扩展名。
下图展示了 X.509 主流证书的编码格式和文件扩展名。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vn3Ha1QU-1654099659180)(https://cdn.jsdelivr.net/gh/Fly0905/note-picture@main/imag/202205281028625.png)]
对于 nginx 和 Tomcat 最常使用的是 PEM (Nginx) 与 PKCS#12(Tomcat),除此之外 Tomcat还支持基于JDK keytool 加密的 JKS 格式。
PEM 格式
大多数 CA (证书颁发机构) 提供 PEM 格式的证书,保存在 Base64 ASCII 编码的文件中。证书文件类型可以是 .pem
、.crt
、.cer
或 .key
。因为是文本类型,所以对文件后缀名不敏感。PEM 文件可以在单个文件中包含服务器证书、中间证书和私钥。服务器证书和中间证书也可以放在单独的 .crt
或 .cer
文件中,私钥可以放在 .key
文件中。
PEM 文件使用 ASCII 编码,可以使用文本编辑器打开,文本内容中公钥、私钥都有两种形式。X.509 规定,取 ----
开头的下一行首开始,到下一个 ----
开头的上一行尾结束。
----BEGIN CERTIFICATE----
公钥加密串
----END CERTIFICATE----
-----BEGIN PUBLIC KEY-----
公钥加密串
-----END PUBLIC KEY-----
---- BEGIN RSA PRIVATE KEY-----
私钥加密串
-----END RSA PRIVATE KEY-----
-----BEGIN PRIVATE KEY-----
私钥加密串
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE REQUEST-----
CSR加密串
-----END CERTIFICATE REQUEST-----
PKCS#7 格式
PKCS#7 格式是一种“加密消息语法标准”。PKCS#7证书使用 Base64 ASCII 编码,文件扩展名为 .p7b
或 .p7c
,这种格式只能存储证书,不能存储私钥。一般主要用来做数字信封。格式如下:
-----BEGIN PKCS7-----
公钥加密串
-----END PKCS7-----
DER 格式
DER 证书采用二进制格式,只含有证书信息,不包含私钥。文件扩展名为 .der
或 .cer
。这些证书主要用于Java Web服务器。
PKCS12 格式
PKCS#12证书采用二进制格式,文件扩展名为 .pfx
或 .p12
,支持将 服务器证书
、中间证书
和 私钥
存储在一个具有密码保护的文件中,主要用于Windows平台。
1.4 Nginx SSL证书配置
Nginx 支持所有 PEM 格式的证书,包含 .pem
、.crt
、.cer
、.key
,其中 .key
常用于私钥后缀名。
server
listen 443 ssl;
server_name www.example.com;
ssl_certificate /path/to/path/public.pem;
ssl_certificate_key /path/to/path/private.key;
ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location /
root html;
index index.html index.htm;
参数说明:
- server_name :域名(不含https://)
- ssl_certificate :【必填】 公钥文件位置
- ssl_certificate_key :【必填】 私钥文件位置
- ssl_session_timeout :客户端可复用会话的时间
- ssl_ciphers:指定启用的加密器类型,必须是OpenSSL库支持的类型,默认 ssl_ciphers HIGH:!aNULL:!MD5;
- ssl_protocols:表示使用的TLS协议的类型,默认是TLSv1 TLSv1.1 TLSv1.2,可选参数为SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2、TLSv1.3
- ssl_prefer_server_ciphers:指定服务端加密器优先,参数为on开启,默认off关闭;
官方文档参考:
- https://nginx.org/en/docs/http/configuring_https_servers.html
- https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
1.5 Tomcat SSL证书配置
Tomcat 支持 JKS、PKCS11 和 PKCS12 格式的密钥库,JKS 格式是 Java 的标准格式,由 JDK 的 keytool 生成;PKCS11/12 是网络标准,由 OpenSSL 生成。
对于证书格式转换,JKS 一般是由 PKCS12 转换而来,Tomcat 又支持 PKCS12 所以只要将 PEM 格式转换成 PKCS12 (.pfx 或 .p12) 即可。参考 [#PEM 格式 转 PKCS#12](#PEM 格式 转 PKCS#12)
server.xml 配置
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="<keystoreFile>" keystorePass="<passvalue>"
clientAuth="false" sslProtocol="TLS"/>
参数说明:
- port :HTTPS 协议端口,可以设置为 443
- protocol :连接协议,由
HTTP/1.1
改为org.apache.coyote.http11.Http11NioProtocol
- keystoreFile :证书文件绝对路径,可以是 JKS 或 PKCS12
- keystorePass :证书的密码
- 未说明的参数除
maxThreads
根据实际情况调整,其余均按照上面的配置即可。
官方文档参考:https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Configuration
1.6 主流证书转换方法
一般来说,阿里云、腾讯云直接提供不同服务器类型的证书,以下证书转换仅当无备选类型时使用。
PEM 格式 转 PKCS#12
PEM 格式的公私钥后缀名不影响转换,可以是 .crt
/.pem
/ .key
/.cer
。
openssl pkcs12 -export -in public.pem -inkey private.key -out keystore.p12 -passout pass:<passvalue>
参数说明:
- -in : 指定PEM 公钥文件
- -inkey:指定 PEM 私钥文件
- -out:指定输出 PKCS#12 格式的证书,常以
.p12
或.pfx
扩展名。 - -passout:指定 PKCS#12 证书的密码
PKCS#12 转 PEM
当提供PKCS#12证书,则需要转换为PEM证书,命令如下:
#导出私钥
openssl pkcs12 -in keystore.p12 -out private.key -nocerts -nodes -password pass:<passvalue>
#导出公钥
openssl pkcs12 -in keystore.p12 -out public.pem -clcerts -nokeys -password pass:<passvalue>
参数说明:
- -in :输入文件,本命令中是 PKCS#12 证书
- -out:输出文件,根据上边两种搭配,分别输出私钥与公钥
- -nocerts:无公钥
- -nodes:不加密私钥。目前在 OpenSSL 3.0 中废弃,使用
-noenc
代替,Git Bash 自带的版本目前还没升到 3.0 - -clcerts:只输出客户端证书
- -nokeys:无私钥
- -password:PKCS#12证书的密码,需要接
pass:<实际密码>
官方文档参考:https://www.openssl.org/docs/manmaster/man1/openssl-pkcs12.html
1.7 证书的类型
按照数字证书的生成方式进行分类,证书有三种类型:
-
由权威 CA 机构签名的证书: 这类证书会被浏览器、小程序等第三方应用/服务商信任
- 申请证书时需要验证你对域名/IP 的所有权,也就使证书无法伪造
- 如果你的 API 需要提供给第三方应用/服务商/用户访问,那就需要向权威 CA 机构申请此类证书
-
-
本地签名证书 -
- 即由本地 CA 证书签名的 TLS 证书
tls_locally_signed_cert
- 本地 CA 证书,就是自己使用
openssl
等工具生成的 CA 证书 - 这类证书的缺点是无法与第三方应用/服务商建立安全的连接
- 如果客户端是完全可控的(比如是自家的 APP,或者是接入了域控的企业局域网设备),完全可以在所有客户端都安装上自己生成的 CA 证书。这种场景下使用此类证书是安全可靠的,可以不向权威 CA 机构申请证书
-
-
自签名证书 -
- 根证书是一个自签名证书,它使用根证书的私钥为根证书签名
tls_self_signed_cert
- 这里的「自签名证书」是指直接使用根证书进行网络通讯,缺点是证书的更新迭代会很麻烦,而且安全性低。
总的来说,权威CA机构颁发的证书,可以被第三方应用信任,但是自己生成的不行。 而越贵的权威证书,安全性与可信度就越高,或者可以保护更多的域名。
在客户端可控的情况下,可以考虑自己生成证书链并签发「本地签名证书」,将本地 CA 证书预先安装在客户端中用于验证。
而「自签名证书」主要是方便,能不用还是尽量不要使用。
1.8 向权威 CA 机构申请「受信证书」
免费的「受信证书」有两种方式获取:
-
申请
Let’s Encrypt 免费证书
- 很多代理工具都有提供 Let’s Encrypt 证书的 Auto Renewal,比如:
- 网上也有一些 certbot 插件,可以通过 DNS 提供商的 API 进行 Let’s Encrypt 证书的 Auto Renewal,比如
- terraform 也有相关 provider: terraform-provider-acme
-
部分认证机构有提供免费证书的申请,有效期为一年,但是不支持泛域名
收费证书可以在各云服务商处购买,比如国内的阿里云、腾讯云等。
完整的证书申请流程如下:
为了方便用户,图中的申请人(Applicant)自行处理的部分,目前很多证书申请网站也可以自动处理,用户只需要提供相关信息即可。
1.9 证书的寿命
对于公开服务,服务端证书的有效期不要超过 825 天(27 个月)! 另外从 2020 年 11 月起,新申请的服务端证书有效期已经缩短到了 398 天(13 个月)。 目前 Apple/Mozilla/Chrome 都发表了相应声明,证书有效期超过上述限制的,将被浏览器/Apple设备禁止使用。
而对于其他用途的证书,如果更换起来很麻烦,可以考虑放宽条件。 比如 kubernetes 集群的加密证书,可以考虑有效期设长一些,比如 10 年。
据云原生安全破局|如何管理周期越来越短的数字证书?所述,大量知名企业如特斯拉/微软/领英/爱立信都曾因未及时更换 TLS 证书导致服务暂时不可用。
因此 TLS 证书最好是设置自动轮转!人工维护不可靠!
目前很多 Web 服务器/代理,都支持自动轮转 Let’s Encrypt 证书。 另外 Vault 等安全工具,也支持自动轮转私有证书。
2. 自签发SSL证书与CA数字证书
自签发 SSL 证书
通过 openssl
生成自签发证书,自签发证书不包含CSR中间证书,直接生成公钥。自签发的证书在网络上是不可信的,但是 内网测试与使用,也是可以的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F75Blb0K-1654099659182)(https://cdn.jsdelivr.net/gh/Fly0905/note-picture@main/imag/202205281028112.png)]
命令如下:
#生成RSA私钥
openssl genrsa -out private.key 2048
#自签发公钥
openssl req -new -x509 -key private.key -out public.pem -days 1095 #3年有效期
CA 数字证书
CA 数字证书是由创建者提供 CSR(Centificate Signing Request)给CA机构签发下来的公钥。
一般来讲,SSL运营商(如阿里云等)已经提供了直接下载指定服务器类型的公私钥功能,以下仅是过程简单描述。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JecdHOhY-1654099659182)(https://cdn.jsdelivr.net/gh/Fly0905/note-picture@main/imag/202205281028106.png)]
CA 机构的处理方式一般不需要创建者关心,命令:
#生成RSA私钥
openssl genrsa -out private.key 2048
#使用私钥生成CSR
openssl req -new -key privkey.key -out cert.csr
将此CSR交给 CA机构 ,由CA签名后获得公钥,使用公钥和私钥就可以部署 HTTPS 服务了。
实操:openssl 自签SSL过程
初始化证书存放目录结构和文件
$ mkdir certs crl csr newcerts private
$ echo 1000 > crlnumber && echo 1000 > serial && touch index.txt
注解:
- private: 存放CA证书的私钥
- certs: 存放CA证书
- netcerts: 存放新生成的服务端或客户端证书,一般以序列号命名
- serial: 序列号,需给定初始值,可随意设置为01,1000等
- index.txt: 文件数据库,签发证书后会更新该数据库
制作CA根证书
# 生成CA根证书私钥:为保证安全,生成一个4096位的私钥,并使用CNs方式加密
$ openssl genrsa -CNs256 -out private/rootca.key 4096
Generating RSA private key, 4096 bit long modulus
....................................................................................................................................................++
........................................................................++
e is 65537 (0x10001)
Enter pass phrase for private/rootca.key: (输入CA私钥保护密码)
Verifying - Enter pass phrase for private/rootca.key: (输入确认CA私钥保护密码)
# 生成自签名的CA根证书
$ openssl req -config openssl.cnf -new -x509 -days 3650 -sha256 -extensions v3_ca -key private/rootca.key -out certs/rootca.cer -subj "/C=CN/L=F/O=kubesre/OU=ACS/CN=*.kubesre.com"
Enter pass phrase for private/rootca.key: (输入CA私钥保护密码)
# 查看证书内容, 以确保证书生成正确
$ openssl x509 -noout -text -in certs/rootca.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
f8:a5:89:11:71:df:45:d1
Signature Algorithm: sha256WithRSCNncryption
Issuer: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=*.kubesre.com
Validity
Not Before: Dec 10 06:43:40 2020 GMT
Not After : Dec 8 06:43:40 2030 GMT
Subject: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=*.kubesre.com
Subject Public Key Info:
Public Key Algorithm: rsCNncryption
Public-Key: (4096 bit)
Modulus:
00:ba:1e:a4:92:bf:25:3d:96:be:0e:af:65:a5:f8:
f0:a9:bc:09:4c:92:af:9a:f4:4b:df:87:2f:a6:56:
d7:4d:4a:28:d1:85:34:58:86:f7:79:30:8c:b2:71:
1f:1c:80:c3:b0:cd:6a:05:b4:e9:8f:8f:3e:eb:76:
8b:2e:66:c7:37:a6:d3:fd:be:23:f4:16:ad:02:ff:
7d:21:a1:ab:f0:39:15:d5:6c:93:a3:89:65:5b:84:
0c:e0:30:fe:b3:e4:f6:7f:42:d9:95:04:d8:23:d2:
2a:c1:63:e2:3c:e2:6b:f7:84:8b:bd:f3:c5:2c:7b:
2a:03:7d:7a:d7:93:b0:20:59:ff:64:2b:84:ac:09:
1d:05:35:2c:68:5a:90:42:ba:2a:54:d5:1b:0f:ec:
93:78:11:85:dc:e0:b5:60:68:46:c4:be:f3:05:b4:
ca:0b:bf:14:1f:a1:be:63:99:0d:f7:a6:90:b5:50:
c8:b2:c9:69:8b:31:e2:f0:b9:ab:62:a3:2b:1b:16:
70:1c:36:f3:79:ab:b4:42:6b:83:8d:f7:d0:8d:d7:
eb:a6:38:50:df:79:57:c0:eb:6c:b0:71:e3:c0:af:
7e:01:83:2e:77:64:b0:80:89:68:82:16:56:0d:69:
30:71:cc:2d:d6:b2:ef:29:c3:e9:46:7c:8e:bd:82:
8f:a9:8c:d0:77:91:1d:7c:9e:d6:18:a8:e8:87:16:
ff:d2:b0:3d:e5:9a:0a:6a:c7:52:f4:ce:95:11:59:
ea:ca:13:f8:4c:55:25:f1:12:2d:93:d6:2a:82:5c:
bf:ca:43:98:3f:ee:38:6a:af:a2:14:7b:61:00:ec:
10:f2:e3:4a:4f:8d:82:5c:9c:2d:ce:88:29:03:b9:
07:77:f6:46:b7:49:ec:c8:e3:13:60:af:a8:f5:a8:
CN:08:57:b3:b9:99:CN:e7:68:2c:9a:e3:ce:ed:7b:
f6:a8:a5:2a:74:73:d6:29:a4:3e:c6:e7:14:e9:4c:
57:b8:d4:91:43:2b:39:5d:7d:6e:34:f4:07:f7:95:
b6:7f:ec:9e:34:48:29:20:6f:aa:48:30:5f:dd:f3:
3a:20:cc:08:d1:4a:8e:d0:ba:60:d5:0a:4d:CN:23:
ed:05:51:88:2d:a9:37:51:54:c3:19:b9:29:ca:e2:
91:ad:1e:12:36:cd:9b:32:79:62:54:16:78:69:1c:
6e:4d:5a:56:a3:da:b2:dd:ac:be:ca:cc:87:ff:97:
76:a5:6d:b9:a8:1f:88:3a:3a:6d:b0:b8:54:17:bc:
92:4d:d6:80:4c:06:48:7e:19:e3:51:d1:a3:5a:0b:
7f:66:06:e7:6b:c2:b3:73:89:3d:bb:7c:1a:5d:31:
ce:ed:71
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F4:DD:78:54:58:68:52:30:88:C1:AD:07:43:BD:14:2D:2D:09:E5:D1
X509v3 Authority Key Identifier:
keyid:F4:DD:78:54:58:68:52:30:88:C1:AD:07:43:BD:14:2D:2D:09:E5:D1
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSCNncryption
63:52:0c:6e:2d:3c:54:1f:d1:aa:88:43:4f:00:04:2e:b7:85:
d8:15:cd:5e:0f:8c:39:e6:80:69:1e:f6:18:f7:5c:a1:f6:e1:
52:ed:c1:ce:89:30:bc:be:cf:22:b3:bb:9b:80:b6:de:6e:49:
47:ec:80:f4:90:11:93:da:59:9d:1f:e9:b0:70:dc:50:74:36:
7e:c8:03:bf:2f:84:50:c1:a0:1c:4e:07:d6:cd:87:a7:b6:35:
35:85:90:9b:72:8b:35:42:cd:82:9a:b6:CN:cd:c6:7d:23:1d:
d8:be:91:65:93:78:ee:e9:72:0e:8d:6f:cc:7c:4a:CN:d5:a6:
a4:0a:f1:b4:cd:c9:29:fb:81:50:58:8c:01:cb:c0:65:a1:61:
46:9e:53:fc:5d:3e:46:5d:b1:b3:49:67:43:3e:80:9f:90:dc:
4a:e1:04:82:e5:4f:11:85:cc:f4:11:82:b0:b2:8f:e0:63:bc:
b6:7f:14:c7:46:f3:84:a7:9b:d5:ca:3e:d7:1d:63:fd:64:4b:
31:3b:b1:69:d2:c8:71:e8:19:d6:6f:5b:21:53:1c:48:65:89:
95:c7:fa:be:b4:1a:42:67:8a:ed:d8:a4:13:a1:39:31:c0:80:
2b:c3:26:05:15:76:cb:7c:52:8a:db:3b:5a:51:70:68:40:ed:
20:6b:ef:ef:86:a4:87:40:ff:39:9e:c0:b2:cf:2d:75:44:b8:
1f:ec:91:e8:06:d2:2d:26:10:e4:04:02:3e:09:96:92:db:ec:
f4:80:e3:5c:dc:f8:fe:ed:09:b4:64:e2:73:1d:db:7d:68:f8:
21:41:a8:5f:5b:4c:66:4f:71:d5:b1:8f:ef:8e:80:91:b8:cb:
a0:ab:dc:9a:6b:e3:7a:12:a0:f6:80:7c:2e:51:c0:45:4a:eb:
f6:78:2d:ff:6a:61:bc:7c:6a:0c:6e:4d:48:0e:fa:5c:84:24:
1b:47:bf:24:be:93:56:6c:f1:15:ad:b7:f0:3d:73:13:d3:ea:
da:bb:55:88:5f:9a:37:a4:3f:da:75:1e:cb:bd:7f:33:51:32:
42:b2:f8:0c:63:c6:c6:4c:56:70:0a:a6:31:f0:f2:22:cf:9d:
fe:78:53:92:2d:56:b9:0a:e2:bd:cd:82:f8:8b:35:29:fc:61:
3c:a6:18:3e:f5:a4:da:aa:5b:fd:aa:15:91:91:b7:d3:89:f9:
c0:b3:f9:f1:22:f8:a6:00:05:44:bf:2b:d6:af:21:98:bd:a3:
39:b2:95:55:e2:f5:28:d9:cf:47:ec:39:12:0a:5e:bf:6d:f0:
e5:dd:5c:26:53:f5:b9:1f:58:22:3f:ba:60:b6:48:49:98:82:
ab:ec:4a:99:86:b9:21:28
制作代理CA证书(中间CA)
制作代理CA证书不是必须的,这里之所以要多次一步,是因为:
- 根证书的安全必须得到充分的保证
2.在实现商业逻辑中,代理CA的存在也是相当普遍
用代理CA签发客户端证书的话,在服务端的配置需要特别注意,以nignx为例:必须设定ssl_verify_depth 2; 即客户端证书链的验证深度, 默认值为1; 因为代理CA之上还有根CA, 所以这里要设置为2, 否则无法校验通过
# 在生成代理CA证书私钥: 同样适用4096位, 不加密了
$ openssl genrsa -out private/intermediateca.key 4096
# 在生成签发请求
$ openssl req -new -key private/intermediateca.key -out csr/intermediateca.csr -subj "/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=Pty Intermediateca CA"
# 用CA根证书签发该代理CA证书请求
$ openssl x509 -req -extfile openssl.cnf -extensions v3_ca -days 3600 -sha256 -CA certs/rootca.cer -CAkey private/rootca.key -CAcreateserial -CAserial serial -in csr/intermediateca.csr -out certs/intermediateca.cer
Signature ok
subject=/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=Pty Intermediateca CA
Getting CA Private Key
Enter pass phrase for private/rootca.key: (输入CA私钥保护密码)
# 查看代理CA证书内容, 以确保证书生成正确
$ openssl x509 -noout -text -in certs/intermediateca.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4097 (0x1001)
Signature Algorithm: sha256WithRSCNncryption
Issuer: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=*.kubesre.com
Validity
Not Before: Dec 10 06:55:30 2020 GMT
Not After : Oct 19 06:55:30 2030 GMT
Subject: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=Pty Intermediateca CA
Subject Public Key Info:
Public Key Algorithm: rsCNncryption
Public-Key: (4096 bit)
Modulus:
00:b2:2d:c6:2e:3a:f0:5a:4b:00:c1:d0:6b:0f:44:
83:3d:9b:3d:9f:c5:41:f8:e6:f5:20:a5:26:61:ac:
cc:55:33:14:76:96:6a:a2:4c:a7:37:bf:47:1f:9d:
54:41:83:3a:2a:9e:8f:b0:5f:d4:38:a5:a5:1d:89:
ea:14:c6:00:b4:3d:11:9e:31:42:a4:c8:5e:32:7b:
00:36:6a:d6:bf:c9:c6:04:e7:1b:2d:33:ea:dd:54:
78:01:aa:dd:a5:21:fc:4f:ce:68:02:d4:43:3b:ea:
a9:80:19:2c:e7:5a:e9:dc:1a:4a:74:47:1f:69:d0:
17:43:a7:c7:03:7e:a8:6a:94:f5:46:7b:5a:e0:93:
c4:b4:7f:dd:56:76:71:09:de:73:57:5d:33:e4:90:
fe:ff:7c:a7:77:0c:7c:37:83:87:a4:3a:7a:ec:a3:
64:6d:90:16:9b:cf:77:38:05:f8:e8:98:d8:07:42:
aa:5e:6a:f5:3c:fb:cb:86:51:b9:d2:30:a4:2c:9a:
5e:fe:07:48:6e:14:43:77:87:d3:b9:52:2f:5b:ef:
a5:e9:6c:3b:0a:c9:c7:aa:6e:db:9b:5e:4a:f3:c4:
a5:73:0b:77:95:c8:57:ba:7b:b0:f1:CN:b4:b1:71:
f9:e1:61:12:7f:5b:1e:21:87:cc:ca:c0:f4:bf:c3:
6c:41:3a:67:09:c9:92:b8:7e:7c:30:00:1b:d3:02:
27:da:ec:02:dd:6a:b3:6c:22:7e:34:af:a2:37:ff:
18:91:e5:c3:22:ca:31:80:73:8e:b8:99:66:6f:b3:
6b:23:a5:2d:83:6d:17:fe:85:89:aa:76:55:dd:86:
06:60:f1:2e:9b:8c:84:b8:15:3d:d8:d8:60:44:34:
bf:ac:45:d0:4c:5f:50:3a:57:78:7e:87:6c:17:bd:
34:CN:53:ff:98:96:f7:c0:38:1b:49:ef:22:92:26:
b8:73:8b:a8:89:f3:55:c9:61:7c:88:93:8d:c8:77:
80:af:e8:1e:94:60:4e:8a:94:27:72:e4:6c:31:01:
e6:06:81:80:68:3e:99:b0:86:53:22:91:49:c7:88:
10:62:8a:f3:5b:ba:a0:1d:47:c6:cc:35:8c:65:27:
de:a0:96:fa:1c:54:3b:52:80:35:af:74:8a:ec:56:
aa:fd:6b:06:2d:64:c1:e0:ee:36:ba:10:af:e3:64:
7b:4c:50:76:40:54:b9:df:1e:d8:67:e7:fc:e2:49:
78:48:57:96:17:91:1d:52:cb:8b:a0:f3:3b:27:98:
0c:f5:dc:1e:97:cc:21:0f:14:4a:2e:53:d6:fb:aa:
7b:63:8f:14:95:2b:b4:9c:97:39:3b:7e:57:26:12:
68:af:03
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
ED:7F:54:BD:21:E8:69:CF:0F:3A:06:8C:CE:A4:B9:33:8C:94:F6:2C
X509v3 Authority Key Identifier:
keyid:F4:DD:78:54:58:68:52:30:88:C1:AD:07:43:BD:14:2D:2D:09:E5:D1
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSCNncryption
90:3f:28:9d:8b:e7:45:46:91:b7:24:6e:b0:d7:85:d3:c2:f3:
ee:05:55:d9:d9:9f:41:05:aa:5c:4d:2c:ca:01:3d:f8:40:1d:
b3:c9:84:c2:47:1c:05:61:c9:46:ac:dd:18:24:fa:5b:69:57:
38:72:7a:16:a6:b7:a7:16:65:f8:84:62:1b:41:34:13:3b:c4:
1b:50:a1:44:35:d8:cf:cd:02:f3:a3:d9:29:6e:4b:61:83:f9:
7f:1a:e0:74:02:8c:5e:02:31:8c:28:b7:10:de:63:c7:86:08:
31:5c:2a:c0:83:4d:01:8b:70:59:69:99:40:be:54:ce:d6:c6:
c3:b9:4b:1f:84:e1:c1:fa:5c:07:ba:74:66:f0:66:db:90:10:
be:d8:3d:a7:cb:e1:33:e3:7c:10:a8:5d:9b:73:96:51:87:41:
e9:2f:8b:e9:88:22:fb:f7:23:7d:e5:b7:04:dc:39:f9:05:80:
4a:21:07:98:f1:49:49:77:b7:a2:33:af:37:aa:10:f3:f6:47:
0d:fb:e3:29:bb:0f:5a:ad:0b:a1:d0:41:26:80:9b:20:4c:b8:
d8:81:40:30:18:66:b6:1c:92:b2:7b:0c:f0:1b:aa:1f:ef:3a:
40:21:a6:3a:13:fa:26:25:f5:08:98:f6:d9:11:ab:f6:9a:4e:
8b:c0:e2:eb:2a:85:77:da:fb:c0:53:b0:d5:7c:a9:7b:6c:93:
be:46:1e:92:92:b4:7d:2f:39:f0:86:8a:67:3c:b1:b5:60:3d:
ca:43:bd:b5:86:15:6e:10:60:d4:af:b4:99:83:b5:52:2a:3b:
27:0d:29:9a:e3:97:c5:15:e3:2b:f7:c0:68:79:93:8d:e8:53:
0f:cd:1d:cf:0c:23:1c:23:d2:e0:ee:32:1c:08:55:7d:ed:e5:
01:1a:ba:40:1d:c8:b1:51:2d:85:0c:5d:a1:30:80:c8:36:5c:
61:d5:e4:35:97:07:46:00:17:e4:ee:2b:f2:e6:77:3d:75:62:
13:a2:5b:63:dc:6c:ed:21:b3:c0:84:06:37:39:c7:f9:65:48:
f0:bb:ba:ab:a1:a7:ce:a0:31:80:99:5e:ce:24:37:1b:05:d5:
4f:41:f9:65:e4:c4:a6:97:23:19:c8:b2:41:86:bb:71:bb:b4:
e0:30:e4:ba:9a:65:76:58:0d:29:03:ad:74:ed:e0:12:f5:f9:
23:65:21:5f:f0:db:b6:4f:9f:1b:2c:b8:13:ff:84:95:34:1c:
31:06:17:50:bf:61:cb:6a:99:74:b5:35:b5:e1:9d:e4:04:53:
52:95:fa:d8:e4:19:bc:3e:f3:1c:0b:ad:d4:a8:f6:c2:16:cc:
55:04:01:a3:b7:af:06:3b
# 用根证书校验代理CA证书, 确认是否通过
$ openssl verify -CAfile certs/rootca.cer certs/intermediateca.cer
certs/intermediateca.cer: OK
# 合并证书链, 在校验代理CA签发的证书时需要使用证书链验证
$ cat certs/intermediateca.cer certs/rootca.cer > certs/intermediateca-chain.cer
生成服务端证书
# 创建基于域名的文件夹, 暂且放在newcerts目录下吧
$ mkdir newcerts/www.kubesre.com
# 生成服务端证书私钥: 期限相对较短, 所以用2048位足以
$ openssl genrsa -out newcerts/www.kubesre.com/server.key 2048
# 生成签发请求
$ openssl req -new -key newcerts/www.kubesre.com/server.key -out newcerts/www.kubesre.com/server.csr -subj "/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=www.kubesre.com"
# 用CA证书签发证书
$ openssl x509 -req -extfile openssl.cnf -extensions usr_cert -days 365 -sha256 -CA certs/rootca.cer -CAkey private/rootca.key -CAserial serial -in newcerts/www.kubesre.com/server.csr -out newcerts/www.kubesre.com/server.cer
Signature ok
subject=/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=www.kubesre.com
Getting CA Private Key
Enter pass phrase for private/rootca.key: (输入CA私钥保护密码)
# 查看生成的证书内容
$ openssl x509 -noout -text -in newcerts/www.kubesre.com/server.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4098 (0x1002)
Signature Algorithm: sha256WithRSCNncryption
Issuer: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=*.kubesre.com
Validity
Not Before: Dec 10 07:09:35 2020 GMT
Not After : Dec 10 07:09:35 2021 GMT
Subject: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=www.kubesre.com
Subject Public Key Info:
Public Key Algorithm: rsCNncryption
Public-Key: (2048 bit)
Modulus:
00:b4:ec:81:9b:e7:f2:6f:51:35:2a:de:5a:0e:11:
f2:d8:c6:3f:b2:d0:0a:b9:ad:84:ba:7f:8d:60:de:
14:b1:18:55:a0:1f:f5:85:4d:2b:c7:b7:2d:4e:6f:
6a:b3:64:b6:b0:54:e7:f3:a8:c4:30:a6:b9:f4:f2:
67:b5:d2:d1:c7:3b:9b:3a:34:32:23:6b:66:fc:f4:
a1:81:b0:f0:76:ee:cd:85:69:c9:f9:b0:1d:d3:0c:
de:c9:f5:de:54:63:a0:f8:c2:57:c1:7f:0e:5c:77:
80:2a:38:39:c2:3c:d0:cc:96:3c:16:32:9c:d5:72:
92:d0:f6:3c:53:05:62:f7:ed:aa:b4:2c:ac:27:dd:
2d:7e:6b:b2:57:3e:e7:59:07:96:a6:e2:cf:f7:34:
85:5b:4e:3e:b1:47:f9:bd:49:24:01:2e:3c:00:18:
46:8f:b3:09:df:ca:71:b3:d3:13:68:19:21:9d:3e:
9d:7b:89:91:fa:a0:80:dd:6b:34:87:ea:58:6e:1f:
9f:32:10:a2:ba:ca:74:84:0a:f7:44:c5:4a:58:fc:
ba:ef:67:76:44:6f:71:b3:67:eb:7b:7d:e7:cc:eb:
fb:a7:55:88:a9:78:1a:9d:96:00:7b:ea:6c:6d:0d:
4f:b1:4b:83:4c:30:c4:a1:de:47:1b:47:84:65:bf:
74:ff
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
82:9D:C2:70:F7:E7:58:77:AB:0A:3A:EB:FD:60:F9:9C:FA:A3:00:EB
X509v3 Authority Key Identifier:
keyid:F4:DD:78:54:58:68:52:30:88:C1:AD:07:43:BD:14:2D:2D:09:E5:D1
Signature Algorithm: sha256WithRSCNncryption
24:3d:13:a1:90:ea:93:e7:12:2f:b7:d8:ea:ec:b1:5e:95:d4:
23:8a:b2:bd:45:2a:6c:79:a8:c3:96:1d:2d:c7:b9:54:e0:a4:
0a:27:3c:d2:4d:2b:3c:d5:fe:e7:b3:35:5f:72:ee:50:87:a6:
e3:1c:00:43:3f:8e:e0:16:ab:c4:be:95:24:33:f9:31:df:b4:
92:33:68:10:68:4f:ce:69:ff:26:d7:6a:dc:01:99:16:59:58:
9d:99:52:19:a3:e5:ad:82:72:6e:0b:2a:86:6b:4d:88:2d:f2:
57:a3:cc:d3:42:9a:CN:ab:af:ea:64:2b:b4:fe:36:a3:60:65:
40:c9:47:4e:ed:e9:4f:92:36:e0:35:ef:96:b3:5c:59:CN:7a:
65:a9:9f:ba:c8:d9:04:a7:4c:ce:26:fd:75:c9:ec:53:f2:1b:
40:ed:60:2d:64:25:81:7a:79:3b:68:22:fd:89:83:14:91:8f:
be:9b:fb:2d:bf:68:5a:2f:c2:1d:ab:00:70:0b:2e:62:ba:c8:
06:4d:d5:ef:7a:a2:3f:75:12:7c:9d:ff:11:74:cc:08:25:d7:
2b:04:ec:ea:ce:4c:01:d4:dd:5b:65:6b:b1:ad:27:ab:2e:4a:
7c:43:c1:2c:91:05:2b:68:dd:7b:a9:8b:a0:d8:ba:4b:94:14:
b8:f4:84:e3:7c:08:5b:66:28:4d:48:7a:5a:e7:d4:01:50:dc:
33:19:91:07:f2:86:cc:c7:e5:e3:02:d5:1d:b3:31:7d:cb:34:
16:37:ab:e4:30:b0:34:0d:1d:b7:73:27:90:75:26:0f:4a:7f:
95:9b:5c:13:a8:89:d3:8d:9b:a5:1a:33:4a:1e:b7:b4:1e:cd:
a6:4f:5e:a9:89:27:f1:88:36:9f:3f:92:24:63:80:4b:5f:66:
3d:14:91:21:1a:37:da:93:e5:86:56:cc:a6:8f:3e:4b:a8:57:
aa:5e:62:bb:4c:8f:99:88:25:9c:a2:7c:f9:2a:94:e9:58:98:
1b:aa:0e:e1:ad:22:af:68:e8:49:1d:14:21:fe:22:91:d3:0a:
99:5a:c8:ad:89:bf:ac:9e:d5:b1:e7:35:67:8c:22:37:6d:2d:
85:8d:45:2f:b4:c8:db:45:d4:79:e0:32:70:66:d3:32:fe:a7:
5e:34:be:a0:5e:b6:54:97:d5:ad:5c:32:6d:f4:14:93:2a:95:
76:57:d1:a2:d0:9b:de:15:09:2d:92:9e:13:85:75:5b:df:2e:
c8:b4:eb:2f:fb:57:6e:ce:04:d2:6a:40:c2:5f:a8:a5:11:82:
0d:0c:9b:65:96:1b:00:7d:25:d1:0e:5f:5f:bf:96:dc:54:8d:
22:e9:8d:49:6a:3f:44:7b
# 使用 根证书链校验生成的服务端证书的正确性
$ openssl verify -CAfile certs/rootca.cer newcerts/www.kubesre.com/server.cer
newcerts/www.kubesre.com/server.cer: OK
# 继续合并证书链, 当然你也可以选择不合并
# 在服务端配置server端的证书时使用改证书链, 可以避免浏览器提示 `Windows没有足够信息, 不能验证该证书`
# 但即便获取到完整的证书链, 依然会提示 `无法将这个证书验证到一个受信任的证书颁发机构`
$ cat newcerts/www.kubesre.com/server.cer certs/rootca.cer > newcerts/www.kubesre.com/server-chain.cer
生成客户端证书
# 如下是生成客户端证书的步骤, 仔细看, 跟生成服务端证书没有差别
# 证书都是正经一样的证书, 只是看你怎么用, 用在哪而已
# 当然你也可以差异化的定制一些东西
$ openssl genrsa -out newcerts/www.kubesre.com/client.key 2048
$ openssl req -new -key newcerts/www.kubesre.com/client.key -out newcerts/www.kubesre.com/client.csr -subj "/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=www.kubesre.com"
$ openssl x509 -req -extfile openssl.cnf -extensions usr_cert -days 365 -sha256 -CA certs/rootca.cer -CAkey private/rootca.key -CAserial serial -in newcerts/www.kubesre.com/client.csr -out newcerts/www.kubesre.com/client.cer
Signature ok
subject=/C=CN/L=shanghai/O=kubesre/OU=ACS/CN=www.kubesre.com
Getting CA Private Key
Enter pass phrase for private/rootca.key (输入CA私钥保护密码)
$ openssl x509 -noout -text -in newcerts/www.kubesre.com/client.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4099 (0x1003)
Signature Algorithm: sha256WithRSCNncryption
Issuer: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=*.kubesre.com
Validity
Not Before: Dec 10 07:20:14 2020 GMT
Not After : Dec 10 07:20:14 2021 GMT
Subject: C=CN, L=shanghai, O=kubesre, OU=ACS, CN=www.kubesre.com
Subject Public Key Info:
Public Key Algorithm: rsCNncryption
Public-Key: (2048 bit)
Modulus:
00:c1:01:51:b3以上是关于Kubernetes证书类型和适用场景的主要内容,如果未能解决你的问题,请参考以下文章
kubernetes(k8s)ingress tls和path的使用
Docker&Kubernetes ❀ Kubernetes集群Pod控制器 - DaemonSet(DS)