目录

数字证书那点事(附CP4D及VCenter7定制TLS证书部署案例参考)

通过IBM CP4D的安装部署以及VMware Center7的TLS定制化证书的操作,讲解数字证书的部分理论和实操。

数字证书那点事(附CP4D及VCenter7定制TLS证书部署案例参考)


[TOC]

1.前言

什么是数字证书?

每个公民都有一张身份证,用于证明自己的身份。

为了防止伪造,身份证统一由公安局进行颁发,公安局对身份证进行了签名背书。

公民之间用身份证来证明自己,但如何证明公安局的身份?

可以利用自签名证书,自己证明自己。

那如何自己证明自己?其实根本无非证明,依靠操作系统天生自带的根证书来证明。

你信不信无所谓,反正操作系统都信任了,那么公安局的身份也就证明了。

本文先介绍部分理论,部分转载网上教程。后续根据实战配置,通过IBM CP4D和Vcenter 7的定制TLS证书案例实战。

1.1 TLS介绍

网络通讯必然有安全要求,包括:

1、身份认证:保护客户端和服务器之间的访问身份,确保访问正确的服务器。

2、数据安全:确保通讯加密,一般采用非对称加密对对称加密的秘钥进行交换,然后用对称加密进行数据传输。

3、数据的完整性:传输内容不被篡改。

在安全领域,SSL(security sockets layer,安全套接层)能够为网络通信提供安全及数据完整性的一种安全协议。

SSL3.0版本以后又被称为TLS。SSL位于TCP与各应用层之间,是操作系统向外提供的API。SSL已不再更新。

关于SSL和TLS的解释如下:

  • SSL:(Secure Socket Layer,安全套接字层),为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层: SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

  • TLS:(Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性。 TLS 1.0是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本,可以理解为SSL 3.1,它是写入了 RFC 的。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

    https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021205806095.png

我们平常一直提及所说的HTTPS ,本质是没有HTTPS 这个协议的,是HTTP + SSL/TLS, 也就是在TCP(负责网络数据传输)和HTTP层之间,增加了一层处理加密信息的模块。

我们先看下TLS1.2版本的握手图

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201225085454974.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201225085518009.png

可以看出,服务器在返回ServerHello后,就返回数字证书(可选项),这里数字证书就出现了。

1.2 摘要和数字签名

在数字证书之前,我们先说下摘要,这里容易混淆。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021213342989.png

摘要一般可以选用MD5算法和SHA算法,由于摘要算法的不可逆性,可以确保数据无法被篡改。严格来说MD5并不能算是一种加密算法,只能说是一种摘要算法(数据摘要算法是密码学算法中非常重要的一个分支,它通过对所有数据提取指纹信息以实现数据签名、数据完整性校验等功能,由于其不可逆性,有时候会被用做敏感信息的加密。

摘要算法也被称为哈希(Hash)算法、散列算法。

SHA系列算法的摘要长度分别为:SHA为20字节(160位)、SHA256为32字节(256位)、 SHA384为48字节(384位)、SHA512为64字节(512位),由于它产生的数据摘要的长度更长,因此更难以发生碰撞,因此也更为安全。

SHA1的应用较为广泛,主要应用于CA和数字证书中,另外在互联网中流行的BT软件中,也是使用SHA1来进行文件校验的。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021213729958.png

【后续证书生成即openssl ca命令中,需要采用sha256,如果采用sha1,谷歌浏览器会提示错误】

【具体提示错误:服务器出示的证书是使用弱签名算法(例如 SHA-1)签署的。这意味着服务器出示的安全凭据可能是伪造的,因此这可能并不是您想要访问的服务器(您可能正在与攻击者进行通信)】

【例如以下内容】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024131342400.png

1.3 数字证书

用私钥加密过的签名就是数字签名了,如前图所示,可以确保数据的完整性。

但是如果用自己私钥加密,将传输中的公钥进行偷换,由于签名未破坏,对方认为是其他人在传输。

问题在于如何确保公钥的身份?

这时候证书出现了。通过固定的第三方进行认证,确保对方身份的正确性。

采用第三方担保,确保数字签名中的发出来的公钥是服务器所提供的。再用证书中服务器的公钥对信息加密,与服务器通信。

1.4 数字证书本质

数字证书的本质就是通过约定的不可伪造的第三方对服务器的公钥和相关信息利用CA的私钥进行加密。

客户端拿到经过CA认证的服务器证书,到CA进行认证,即利用计算机上的CA公钥进行解密,解密后通过核对签名,确认服务器的身份的正确性。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021214138383.png

最终数据通过数字签名+数字证书进行组合发送。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021221023533.png

CA证书是由CA(Certification Authority)机构发布的数字证书。

例如访问百度

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021221419224.png

这里的GlobalSIgn Root CA就是根证书颁发机构,【而GlobalSign Organization Validation CA - SHA256 - G2就是中级证书颁发机构】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021221450859.png

1个有效的证书包括了颁发者、使用者、版本、签名算法、签名哈希算法、使用者、公钥、指纹、指纹算法

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201021221547173.png

本文重点介绍如何利用自签名的CA根证书颁发证书,并通过几个案例重点介绍如何自定义TLS证书。

2.基本概念

2.1 证书用途

谓数字证书,是一种用于电脑的身份识别机制。由数字证书颁发机构(CA)对使用私钥创建的签名请求文件做的签名(盖章),表示CA结构对证书持有者的认可。

几个基本概念:

1、身份验证(验证对方确实是对方声称的对象)。

2、加密通信,实现数据传输过程中的加密和解密。

3、数据完整性(无法被修改,修改了会被知)。

2.2 证书格式

x509的证书编码格式有两种PEM和DER两种格式。

1、PEM[Privacy-enhanced Electronic Mail]

PEM是明文格式的

【以 —–BEGIN CERTIFICATE—–开头,以—–END CERTIFICATE—–结尾】

中间是经过base64编码的内容,apache需要的证书就是这类编码的证书。

Base64编码是从二进制到字符的过程。

查看这类证书的信息的命令为 :openssl x509 -noout -text -in server.pem

【PEM就是把DER的内容进行了一次base64编码】

Pem格式证书可用于linux/nginx/node.js格式客户端,后续范例里IBM CP4D系统的自定义TLS证书,就是自定义nginx的TLS证书。

2、DER

DER是二进制格式的证书 , 查看这类证书的信息的命令为 :openssl x509 -noout -text -inform der -in server.der

2.3 X.509证书三个文件

在密码学中,X.509是一个标准,规范了公开秘钥认证、证书吊销列表、授权凭证、凭证路径验证算法等

X.509证书包含三个文件:key,csr,crt。

1、key是服务器上的私钥文件,用于对发送给客户端数据的加密,以及对从客户端接收到数据的解密。可以是DER编码的或者是PEM编码的 查看DER编码的(公钥或者密钥)的文件的命令为 openssl rsa -inform DER -noout -text -in xxx.key 查看PEM编码的(公钥或者密钥)的文件的命令为 openssl rsa -inform PEM -noout -text -in xxx.key

2、csr是证书签名请求文件,用于提交给证书颁发机构(CA)对证书签名,生成请求以后发送给CA,然后CA会给你签名并发回证书。

3、crt是由证书颁发机构(CA)签名后的证书,或者是开发者自签名的证书,包含证书持有人的信息,持有人的公钥,以及签署者的签名等信息。可以是DER(二进制)编码的,也可以是PEM( ASCII (Base64) )编码的。Windows系统常见为.cet后缀名。

3.自签名证书分类

自签名证书分为自签名私有证书和自签名CA证书两种。

【 区别:自签名私有证书无法被吊销,自签名CA证书可以被吊销。】

能不能吊销证书的区别在于如果私钥不小心被恶意获取,如果证书不能被吊销那么黑客很有可能伪装成受信任的客户端与用户进行通信。如果你的规划需要创建多个客户端证书,那么使用自建 CA 签名证书的方法比较合适,只要给所有的客户端都安装了 CA 根证书,那么以该 CA 根证书签名过的客户端证书都是信任的,不需要重复的安装客户端证书。

请注意由于是自建 CA 证书,在使用这个临时证书的时候,会在客户端浏览器报一个错误,签名证书授权未知或不可(signing certificate authority is unknown and not trusted.),但只要配置正确,继续操作并不会影响正常通信。

自签名证书的 Issuer 和 Subject 是一样的。下面就分别阐述如何使用 OpenSSL 生成这两种自签名证书。

3.1 Openssl命令相关解释

安装Openssl

1
yum -y install openssl

如果需要keytool工具,安装jdk包即可。【本文不对keytool进行描述】

1
2
yum search jdk
yum -y install java-1.8.0-openjdk.x86_64

Openssl的命令就这么点,解释如下:

设定选项 设定选项说明
openssl req 创建证书签名请求等功能
-nodes 对私钥不进行加密
-newkey 创建CSR证书签名文件和RSA私钥文件
rsa:2048 指定创建的RSA私钥长度为2048
-keyout 创建的私钥文件名称
-out 指定CSR输出文件名
-subj 指定证书Subject内容

Subject设定内容说明

字段 含义 设定值例
/C= Country CN
/ST= State SHANGHAI
/L= Location SH
/O= Organization CJ
/OU= Organizational IT
/CN= Common Name openshift4.cj.io

3.2 Openssl配置文件解释

【修改OpenSSL的配置】,默认配置文件路径是/etc/pki/tls/openssl.cnf

【openssl.cnf】

1
2
3
4
5
[ CA_default ]
dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
1
2
3
4
5
6
7
# /etc/pki/CA 路径下
[root@support CA]$tree
.
├── certs
├── crl
├── newcerts
└── private

【相关说明】

certs目录存放已颁发的证书

newcerts目录存放CA指令生成的新证书

private目录存放私钥

crl目录存放已吊销的整数

index.txt:OpenSSL定义的已签发证书的文本数据库文件,这个文件通常在初始化的时候是空的

serial:证书签发时使用的序列号参考文件,该文件的序列号是以16进制格式进行存放的,该文件必须提供并且包含一个有效的序列号

【为后续做部分修改,否则通过openssl ca命令给服务器签名会提示ca证书和秘钥路径不对,】

【默认ca私钥路径,openssl ca制定的ca私钥路径】

1
2
3
4
5
6
7
private_key     = $dir/private/cakey.pem# The private key
# 修改为
private_key     = $dir/private/ca.key

certificate     = $dir/cacert.pem       # The CA certificate
# 修改为
certificate     = $dir/certs/ca.crt 

【basicConstraints字段说明】

1、生成证书请求文件的时候。读者可查看openssl.cnf中[req]字段中扩展字段是v3_req,在v3_req中有个basicConstraints变量。

当basicConstraints=CA:TRUE时,表明要生成的证书请求是CA证书请求文件;

当basicConstraints=CA:FALSE时,表明要生成的证书请求文件是终端证书请求文件;

2、在签发证书的时候。签发终端证书的时候使用默认扩展字段usr_cert,当签发CA证书的时候再命令行使用了extensions选项指定v3_ca字段。

在默认的usr_cert字段中 basicConstraints=CA:FALSE;表明要签发终端证书;

而在v3_ca字段中 basicConstraints=CA:TRUE;表明要签发CA证书;

3.3 修改OpenSSL的配置

默认配置文件路劲是/etc/pki/tls/openssl.cnf

这里的[ v3_req ]和[ v3_ca ],

在openssl x509命令中,通过 -extensions参数,例如CA根证书自签名时候按照openssl.cnf文件中配置的v3_ca项添加扩展,这个很重要。是v3_ca是代表是签名根证书。给服务器签名时候,配置v3_req 。

【去掉[req_distinguished_name]里0.xxx开头的部分】

【修改[ v3_req ]和[ v3_ca ]内容】

【添加subjectAltName = @alt_names,及[ alt_names ]字段】,

【可以不在-extensions参数及openssl.cnf定义,可以通过-extfile参数定义SAN,具体查看6.3.1章节内容。】【建议单独配置extfile文件配置SAN属性】

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
[ req ]
# req_extensions = v3_req注释取消掉
req_extensions = v3_req


# 修改[ v3_req ]和[ v3_ca ]内容

[ v3_req ]
basicConstraints = CA:FALSE
# 数字签名, 不拒绝, 密钥加密
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# 增强型密钥用法,服务端验证
extendedKeyUsage=serverAuth
# 添加这里的相关信息,具体看后续[ alt_names ]字段信息
subjectAltName = @alt_names


[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# 去掉[req_distinguished_name]里0.xxx开头的部分

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = XX
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
#stateOrProvinceName_default    = Default Province

localityName                    = Locality Name (eg, city)
localityName_default            = Default City

#0.organizationName             = Organization Name (eg, company)
#0.organizationName_default     = Default Company Ltd

# we can do this but it is not needed normally :-)
#1.organizationName             = Second Organization Name (eg, company)
#1.organizationName_default     = World Wide Web Pty Ltd

[ alt_names ]
DNS.1=cp4d-cpd-cp4d.apps.openshift4.cj.io
DNS.2=www.cp4d-cpd-cp4d.apps.openshift4.cj.io
# 如果是IP地址类
IP.1 =172.18.1.30
IP.2 =172.18.1.31

4.自签名CA根证书

重点介绍如何利用自签名的CA根证书,及给服务器证书和客户端证书颁发证书。

**提前说明的是:自签名证书是不安全的,存在安全漏洞。**但可以省去向CA申请的费用。

1、自签证书最容易受到SSL中间人攻击

自签证书是不会被浏览器所信任的证书,用户在访问自签证书时,浏览器会警告用户此证书不受信任,需要人工确认是否信任此证书。所有使用自签证书的网站都明确地告诉用户出现这种情况,用户必须点信任并继续浏览!这就给中间人攻击造成了可之机。

2、自签证书支持不安全的SSL通信重新协商机制

几乎所有使用自签SSL证书的服务器都存在不安全的SSL通信重新协商安全漏洞,这是SSL协议的安全漏洞,由于自签证书系统并没有跟踪最新的技术而没有及时补漏!此漏洞会被黑客利用而截获用户的加密信息,如银行账户和密码等,非常危险,一定要及时修补。

3、自签证书使用不安全的1024位非对称密钥对

而目前几乎所有自签证书都是1024位,自签根证书也都是1024位,当然都是不安全的。还是那句话:由于部署自签SSL证书而无法获得专业SSL证书提供商的专业指导,根本就不知道1024位已经不安全了

4、自签证书证书有效期太长

自签证书中还有一个普遍的问题是证书有效期太长,短则5年,长则20年、30年的都有,并且还都是使用不安全1024位加密算法。可能是自签证书制作时反正又不要钱,就多发几年吧,而根本不知道PKI技术标准中为何要限制证书有效期的基本原理是:有效期越长,就越有可能被黑客破解,因为他有足够长的时间(20年)来破解你的加密。

4.1 准备工作

进入工作目录

1
cd /etc/pki/CA

注:certs目录存放已颁发的证书

newcerts目录存放CA指令生成的新证书

private目录存放私钥

crl目录存放已吊销的整数

index.txt:OpenSSL定义的已签发证书的文本数据库文件,这个文件通常在初始化的时候是空的

serial:证书签发时使用的序列号参考文件,该文件的序列号是以16进制格式进行存放的,该文件必须提供并且包含一个有效的序列号

生成一个随机数

1
2
3
4
[root@support CA]$openssl rand -out private/.rand 1000
# 验证
[root@support CA]$ls private -a
.  ..  .rand

【生成序列号参考文件】【否则openssl ca 命令报错】

1
2
[root@support CA]$touch index.txt
[root@support CA]$echo 01 > serial

验证

1
2
3
4
5
6
7
8
[root@support certifacation]$tree
.
├── certs
├── crl
├── index.txt
├── newcerts
├── privatekey
└── serial

【生成随机数】

1
2
[root@support CA]$openssl rand -out private/.rand 1000
# rand——生成随机数   -out——指定输出文件  1000——指定随机数长度

4.2 生成根证书私钥

利用openssl genrsa生成根证书私钥(pem文件)

1
2
3
4
5
6
7
8
[root@support CA]$openssl genrsa -out private/ca.key 2048
Generating RSA private key, 2048 bit long modulus
.....................................................................................+++
......................+++
e is 65537 (0x10001)
# genrsa——使用RSA算法产生私钥
# -out——输出文件的路径
# 2048——指定私钥长度

【这里注意,生成的私钥,文件名要选择为ca.key】

【如果要对私钥进行传输/备份,建议先对私钥进行密码加密】

1
2
3
4
5
[root@support CA]$openssl rsa -in private/ca.key -aes256 -out private/encrypted_ca.key
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
# -aes256——使用256位密钥的AES算法对私钥进行加密

验证生成文件,以及查看私钥信息。

1
2
3
4
5
6
7
[root@support CA]$ll -a private/
total 12
drwx------. 2 root root   57 Oct 24 09:34 .
drwxr-xr-x. 6 root root   61 Oct  3 14:21 ..
-rw-r--r--. 1 root root 1675 Oct 24 09:32 ca.key
-rw-r--r--. 1 root root 1766 Oct 24 09:34 encrypted_ca.key
-rw-r--r--. 1 root root 1000 Oct 24 09:17 .rand
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
# 查看私钥
[root@support CA]$openssl rsa -noout -text -in private/ca.key

Private-Key: (2048 bit)
modulus:
    00:b5:d7:95:2a:69:5b:ac:4e:75:61:4e:c4:58:71:
    ef:e9:5f:e7:2c:3b:cd:b4:14:b1:95:dd:41:33:db:
    94:62:f2:6c:78:ae:a6:f3:2b:3b:3b:0d:2c:6b:03:
    d2:6d:0f:b6:71:e2:07:fb:60:c9:3e:58:84:77:4b:
    a7:5f:f5:4e:9f:11:a8:b6:80:a8:55:f6:25:4c:f8:
    22:22:02:0a:57:43:81:6f:1e:e7:a9:d7:d3:0d:05:
    66:7c:c8:04:84:fc:ab:35:5b:a8:9d:05:87:ad:33:
    5b:0e:5e:44:bb:b6:0e:2e:bb:0a:cd:11:46:e8:49:
    07:08:b8:8c:38:23:fb:7d:7d:d4:95:43:8e:9b:84:
    6f:d4:48:77:b0🇩🇪01:58:6c:b1:09:f9:3b🆎12:
    86:19:2f:d2:6e:bd:52🇩🇪2c:23:63:bf:45:38:e2:
    49:b4:1d:1c:66:c6:a2:b5:ef:5c:82:4d:68:35:71:
    96:78:68🇩🇪7e:c8:2f:b6:8d:c0:d4:ca:22:06:8a:
    3e:d5:24:99:91:6f:86:82:7f:9b:e4:20:d4:4b:f4:
    27:1d:90:9e:60:dd:b0:38:18:84:84:47:78:ef:bd:
    87:a7:0a:f1:e6:6c:f0💿7c:6a:2d:83:cb:80:aa:
    51:0a:ac:13:f5:c7:08:7f:f4:0b:6b:3c:bf:d3:b9:
    fa:b3
publicExponent: 65537 (0x10001)
privateExponent:
    5d:93:33:ea:a0:4f:11:8b:4a:72:29:b3:76:84:23:
    5e:68:00:b1:4d:91:1c:73:6d:b3:5e:29:58:83:4d:
    87:e1:92:9a:43🇩🇪1b:d2:8a:67:67:ef:0c:9e:e9:
    e1:3f:ad:b6:4b:07:aa:7f:72:f0:07:63:1b:74:ae:
    0b:fe:53:58:1e:21:40:d1:52:4e:f2:1c:dd:cf:ee:
    d8🆎4e:20:fb:d7:16:94:c3:c8:2e:0d:28:6d:38:
    01:4c:78:ae:ea:cb:3b:e9:10:0a:c5:b6:bd:15:69:
    6d:2a:6b:9a:61:24:49:3d:ed:5f:fb:dd:0e:59:ce:
    29:d9:b6:26:89:b5:b8:2c:72:c8:c4:5e:01:5c:96:
    dd:8d:54:d2:be:75:4d:76:1f:40:33:37:79:7f:a7:
    b3:b0:bd:cf:e3:cf:03:01:99:8a:a7:bc:0c:93:c6:
    c7:ae:5b:42:59:15:93:38:41:91:71:d8:cc:18:65:
    30:05:f6:1d:03:78:b0:18:65:09:7a:1f:34:28:73:
    15:87:5c:46:ea:03:67:e5:58:e0:23:5a:26:98:46:
    b0:d3:c1🆎80:68:36:e0:e7:1b:6d:a8:b1:37:ce:
    58:24:53:f3:f3:70:8b:90:15:df:ce:ef:de:ac:ce:
    9c:b1:d4:b4:b3:37:77:76:11💿9f:48:f0:0a:24:
    59
prime1:
    00:e9:18:a2:31:31:05:e2:b6:37:0c:f2:7c:34:83:
    03:51:ed:eb:4d:99:7f:3d:ab:7a:d6:fc:7e:09:a3:
    10:e3:9d:7f:d2:97:bb:3b:50:c3:9e:80:c5:fd:42:
    10:a8:2a:05:bd:7a:76:d0:24:62:55:8e:60:dc:c5:
    55:37:e6:95:0a:69:c6:b1:ba:91:21:3c:fb:37:56:
    e0:06:79:c4:47:65:4c:69:27:0a:f7:0c:ce:0c:4f:
    48:0b:6b:fe:67:09:69:28:22:d6:8f:8e:55:d3:22:
    0b:a1:f9:4b:50:c2:02:ee:6b:01:18:b6:ba:dd:40:
    2c:9c:e3:15:cd:f6:f8:2e:b5
prime2:
    00:c7:b5:b0:75:08:76:4e:4f:5e:6c:40:f1:19:5b:
    70:74:b7:da:29:c1:e0:e1:d9:f0:e0:a1:78:f6:36:
    2c:e4:c2:38:fd:80:3f:6b:84:27:f0:7f:c6:46:08:
    aa:8e:a6:b2:8b:2d:03:cc:4c:8c:25:b4:62:e0:c7:
    a1:53:32:36:54:fb:5e:e9:11:0d:c6:4c:f3:d1:35:
    8f:c6:13:92:f7:79:f1:ac:a1:e3:86:7f:04:53:14:
    91:1e:c8:d5:8f:47:2d:4a:96:c6:33:ee:89:81:6f:
    87:73:d5:3c:ff:9a:1d:39:07:a4:b7:4a:11:e9:f6:
    89:f1:b7:f1:74:a8:36:7c:c7
exponent1:
    59:6b:56:c5:12:2e:54:d3:5b:f8:fe:88:c1:48:45:
    1c:c7:ed:8d:7e:45:fe:ad:6a:d9:50:51:35:77:35:
    c2:6b:a8:1e:6c:90:a9:e7:88:b3:a4:68:cf:87:e9:
    85:e9:60:fc:58:1f:7e:27:87:05:95:31:f9:5f:46:
    1a:c4:bd:06:1a:9f:db:8c:5b:a2:69:97:61:9a:55:
    24:86:cf:d2:27:bd:11:55:a5:f2:32:1a:55:44:90:
    b9:b8:fb:06:21:e9:12:39:93:1f:cd:15:85:82:38:
    fe:30:f9:40:88:bc:c1:23:91:6f:1e:a2:3e:c0:20:
    9d:2a:cc:31:8f:fd:93:45
exponent2:
    12:35:e7:19:44:e4:44:cf:c7:f4:67:17:95:10:59:
    78:cb:2b:01:93:c4:45:d3:f1:bb:09:fe:55:b5:2a:
    f2:d1:23:11:3a:98:8d:dd:47:27:0e:ff:ad:73:2c:
    da:45:29:12:b7:d0:18:d9:02:0e:8e:1c:56:12:de:
    0b:10:11:14:3e:b7:b0:d8:f5:40:97:d3:c3:c7:f6:
    8c:41:4c:ad:74:59:2d:3c:b5:da:95:ca:77:28:f0:
    f2:b5:ad:83:9b:21:ee:23:41:7f:8a:c8:cf:1c:b4:
    65:43:94:84:5a:31:3f:fa:0a:73:0c:36:05:f7:8d:
    2c:95:71:57:09:df:ae:11
coefficient:
    1f:42:83:f6:ce:f1:24:46:24:58:67:9a:6b:28:fe:
    98:a7:28:7c:6d:67:c3:66:f6:89:e1:e8:ac:d1:e4:
    a2:73:da:57:e4:c4:df:54:7d:ff:ad:6f:1d:e3:6d:
    67:bc:89:52:ad:0e:10:1d:fc:1e:ec:2f:a8:02:bc:
    60:96:6f:e5:85:6f:12:cf:f3:1d:5d:7c:b4:e7:4b:
    9b:d0:60:7b:d2:06:e7:9a:c3:74:cb:55:c5:2d:f1:
    93:bb:8d:1a:80:d6:27:22:94:ea:52:94:50:d9:9f:
    c3:59:2a:64:5a:db:08:fc:e7:a8:9b:2d:26:13:b0:
    c7:2d:af:74:6a:a6:25:f9

4.3 生成根证书签名请求文件

1
2
3
4
5
6
[root@support certifacation]$openssl req -new \
-key private/ca.key \
-out private/ca.csr \
-subj "/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn"

# 如果前述ca.key是包括密码的,那么这里输入秘钥密码,只要后续用到秘钥地方,均需要输入秘钥密码。

验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
[root@support CA]$openssl req -noout -text -in private/ca.csr
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CN, ST=SHANGHAI, L=SH, O=CJ, OU=IT, CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b5:d7:95:2a:69:5b:ac:4e:75:61:4e:c4:58:71:
                    ef:e9:5f:e7:2c:3b:cd:b4:14:b1:95:dd:41:33:db:
                    94:62:f2:6c:78:ae:a6:f3:2b:3b:3b:0d:2c:6b:03:
                    d2:6d:0f:b6:71:e2:07:fb:60:c9:3e:58:84:77:4b:
                    a7:5f:f5:4e:9f:11:a8:b6:80:a8:55:f6:25:4c:f8:
                    22:22:02:0a:57:43:81:6f:1e:e7:a9:d7:d3:0d:05:
                    66:7c:c8:04:84:fc:ab:35:5b:a8:9d:05:87:ad:33:
                    5b:0e:5e:44:bb:b6:0e:2e:bb:0a:cd:11:46:e8:49:
                    07:08:b8:8c:38:23:fb:7d:7d:d4:95:43:8e:9b:84:
                    6f:d4:48:77:b0🇩🇪01:58:6c:b1:09:f9:3b🆎12:
                    86:19:2f:d2:6e:bd:52🇩🇪2c:23:63:bf:45:38:e2:
                    49:b4:1d:1c:66:c6:a2:b5:ef:5c:82:4d:68:35:71:
                    96:78:68🇩🇪7e:c8:2f:b6:8d:c0:d4:ca:22:06:8a:
                    3e:d5:24:99:91:6f:86:82:7f:9b:e4:20:d4:4b:f4:
                    27:1d:90:9e:60:dd:b0:38:18:84:84:47:78:ef:bd:
                    87:a7:0a:f1:e6:6c:f0💿7c:6a:2d:83:cb:80:aa:
                    51:0a:ac:13:f5:c7:08:7f:f4:0b:6b:3c:bf:d3:b9:
                    fa:b3
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    # 这里的RSA256
    Signature Algorithm: sha256WithRSAEncryption
         87:ea:c3:11:11:91:ed:94:23:5b:c7:ff:f1:33:69:7b:df:3d:
         e9:d4:56:a4:70:21:29:b1:43:ad:70:ea:1e:13:3d:79:1b:17:
         09:fc:e4:d7:c6:68:e6:c0:b0:7c:c1:0e:ea:59:8c:75:a8:bb:
         b9:9d:2d:ce:44:37:3e:9a:d7:6a:73:ba:3e:99:a2:e1:d2:e3:
         5a:ca:3f🇩🇪52:44:54:99:2f:69:3c:be:99:f1:27:b8:b2:5d:
         aa:bb:db:16:ff:b5:a5:a6:e2:66:0b:90:8c:77:75:b1:93:24:
         20:84:97:05:09:d5:d7:29:92:da:96🆎08:aa:c9:ba:d8:ca:
         9d:b7:e5:e2:f3:84:d7:07:10:ad:cd:c8:32:7a:94:da:2f:be:
         0f:fe:00:86:f9:6c:71:50:ab:e6:e7:96:42:65:69:89:7d:63:
         9d:0b:12:9e:b2:75:d4:a9:4e:f4:8b:14:0f:5b:33:fc:49:15:
         4e:64:5b:1c:b3:df:54:54:8e:00:c3:b6:c5:d7:46:8b:a5:4a:
         19:bc:de:cf:91:44:cb💿2d:44:af:b6:a3:fa:1f:1d:dd:ac:
         4f:3f:ce:c1:ab:83:72:fe:9f:f0:5a:b8:26:14:9d:f6:8f:95:
         b5:07:b5:93:f3:94:9a:65:f5:3b:26:29:9b:83:b6:2f:45:88:
         59:68:1f:55

4.4 自签名根证书

开始正式签名根证书,前述自签名的私有证书可以选择自签名,也可以选择用这里的自签名的CA根证书签名。

当然这里的根证书也可以找其他CA进行签名。

这里使用了-extensions v3_ca,表示CA扩展为true,具体查看3.3章节内容。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
[root@support certifacation]$openssl x509 -req -days 3650 -sha256 -extensions v3_ca -extfile /etc/pki/tls/openssl.cnf -signkey private/ca.key -in private/ca.csr -out certs/ca.crt

Signature ok
subject=/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn
Getting Private key
Enter pass phrase for privatekey/cakey.pem:


# x509——生成x509格式证书
# -req——输入csr文件
# -days——证书的有效期(天),这里是10年有效期,这里根证书有效期可以10年,服务器及客户端证书不能超过825天,否则谷歌浏览器报错
# -sha1——证书摘要采用sha1算法
# -extensions——按照openssl.cnf文件中配置的v3_ca项添加扩展,这个很重要。是v3_ca是代表是签名根证书
# -signkey——签发证书的私钥
# -in——要输入的csr文件
# -out——输出的cer证书文件

【关于-extensions的说明】

在OpenSSL的配置中,[v3_req]配置的basicConstraints的值为CA:FALSE,

而前面生成根证书时,使用的-extensions值为v3_ca,[v3_ca]中指定的basicConstraints的值为CA:TRUE,表示该证书是颁发给CA机构的证书。具体查看3.3章节内容。

【验证】

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[root@support CA]$openssl x509 -noout -text -in certs/ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            f8:02:e2:49:d4:f4:7c:07
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=SHANGHAI, L=SH, O=CJ, OU=IT, CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn
        Validity
            Not Before: Nov  9 14:19:06 2020 GMT
            Not After : Nov  7 14:19:06 2030 GMT
        Subject: C=CN, ST=SHANGHAI, L=SH, O=CJ, OU=IT, CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:dd:d0:34:74:d2:96:e5:c5:7f:31:29:02:33:72:
                    72:0f:9b:df:a3:54:2a:4f:29:20:0e:8b:91:44:92:
                    b9:1b:04:2c:7e:31:2a:36:26:96:4a:1d:26:78:15:
                    36:2b:77:82:91:fa:5a:ca:8b:7e:ad:83:0d:af:c3:
                    4c:4d:c2:d9:98:40:ae:6b:e2:7e:41:e4:2c:4a:45:
                    84:fe:62:9b:fa:eb:37:94:50:4a:ab:d8:31:94:93:
                    99:d4:87:5a:8f:5d:86:7a:c3:a4:f4:85:80:68:ca:
                    3a:00:fb:59:d0:ff:b3:e1:9f:68:12:fb:2e:a1:eb:
                    d5:ef:98:4e:f9:22:02:58:be:bb:12:d1:53:77:e2:
                    92:d1:95:4c:f4:c9:3f:18:64:9e:17:1b:ab:a0:37:
                    95:ac:e0:3b:4d:0f:2c:c8:de:cf:78:eb:5d:3c:3c:
                    81:c8:e2:93:25:67:29:a0:42:82:8c:f5:11:bf:a3:
                    5f:6d:4d:5d:d8:51:45:6e:5c:9d:5e:9b:2a:07:a2:
                    48:cf:49:8a:5a:a1:e7:f0:68:99:c8:46:b2:9b:6b:
                    97:cc:1e:dc:36:56:54:c3:f9:9b:dc:dd:83:d0:58:
                    e4:c5:04:7c:29:56:e3:52:16:a9:d4:33:f4:c7:cc:
                    9a:61:0f:58:41:c3:5e:4d:83:70:a4:35:3c:8e:9a:
                    62:3d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                8C:41:B9:5E:E8:15:D4:B5:BC:95:4E:CB:3A:BF:5C:56:F7:67:A8:59
            X509v3 Authority Key Identifier:
                keyid:8C:41:B9:5E:E8:15:D4:B5:BC:95:4E:CB:3A:BF:5C:56:F7:67:A8:59
# CA扩展 CA:TRUE,这里很重要
            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         8d:13:20:c5:30:69:8f:12:ac:3a:2b:ec:04:ec:55:d1:04:64:
         29:3a:d8:24:d6:c6:43:ce:ad:b2:3e:33:e5:5c:f0:58:c2:61:
         c6:89:33:f3:34:85:76:63:f8:cb:2a:93:01:4a:34:35:c0:8a:
         74:4a:d2:8d:d9:f4:ea:45:92:8a:3f:17:87:9d:9a:f6:c7:0e:
         fc:e8:50:08:75:91:26:b3:2e:e1:a0:56:21:68:bd:c9:70:fb:
         43:88:46:1e:24:db:71:79:b5:5c:38:be:2e:a6:f4:1c:d7:fc:
         f2:c8:35:81:53:73:0f:28:e7:f8:bb:c4:e7:8e:8d:5b:8c:7b:
         20:ec:d8:20:21:5f:dc:c0:f3:85:f2:8d:fa:13:87:fb:a6:36:
         59:c1:dd:52:47:66:3d:aa:c8:2e:38:9b:7b:0f:b1:c0:b3:a0:
         16:77:4c:0d:7d:e9:88:69:30:da:be:d8:a9:e1:b4:9a:69:1c:
         78:76:09:8e:e0:9a:f7:4a:55:1a:6e:6b:23:7f:2b:4d:4a:b8:
         d8:d3:0b:be:ec:1c:e5:75:72:83:1f:76:b0:13:96:17:b1:b0:
         6c:29:f5:e3:d9:cf:7e:c2:0b:56:ec:55:7b:fa:05:6b:80:d6:
         91:ae:1c:d8:19:2d:5a:25:e6:52:e4:11:b4:46:bf:ce:b3:64:
         73:68:96:5d

【至此,自定义的CA根证书已完成,请妥善保管,后续各系统服务器的TLS证书,均需要通过自定义的CA根证书进行生产】

5.自签名私有证书

自签名私有证书使用起来比较方便,直接生成且自签名。

自签名的原理是用私钥对该私钥生成的证书请求进行签名,生成证书文件。该证书的签发者就是自己,所以验证方必须有该证书的私钥才能对签发信息进行验证,所以要么验证方信任一切证书,面临冒名顶替的风险,要么被验证方的私钥(或加密过的私钥)需要发送到验证方手中,面临私钥泄露的风险。

自签名证书适合很多场景,比如需要内部通讯的两台电脑需要使用加密又不想用第三方证书,可以在两端使用相同的私钥和证书进行验证(当然这样就跟对称加密没有区别了)

再例如镜像仓库,在服务端生成自签名私有证书后,客户端拷贝至本地更新即可。

但自签名私有证书无法被吊销。如果你需要第二个证书,则还需要逐个给所有的客户端安装第二个证书才会被信任。

1
2
3
4
# sample
cp -f server.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust是更新系统的证书目录
update-ca-trust

生成自签名私有证书包括:生成私钥、书签名请求文件以及生成证书几个步骤,可以利用一步合成。

具体如下:

1
2
3
4
5
6
7
openssl req \
-newkey rsa:4096 \
-nodes -sha256 \
-keyout /root/certification/server.key \ 
-x509 -days 3650 \
-out /root/certification/server.crt \
-subj "/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=registry.cj.io/emailAddress=admin@cj.io"

-new选项一般需要结合genrsa子命令创建私钥之后创建CSR文件

而-newkey则可使用一行命令同时完成私钥和CSR文件的创建

如果私钥选择加密,可以选择-des3 用于生成保护密码的私钥文件或者-aes256方式。

注:-subj相关字段需要调整,其中-x509 -days 有效期是多少天。

命令同时生成了私钥和CSR文件。分别是server.key和server.crt。

注意:如果为了https申请,CN这个字段需要注意,这个必须和域名吻合,否则会引发浏览器警报。

6.利用自签名CA根证书给证书签名

【此章节为本文重点部分】

【整体逻辑示意图如下】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024175453969.png

我们可以用CA根证书签发证书,也可以创建中间CA,使用中间CA签发证书。

创建中间CA的好处是即使中间CA的私钥泄露,造成的影响也是可控的,我们只需要使用root CA撤销对应中间CA的证书即可。

此外root CA的私钥可以脱机妥善保存,只需要在撤销和更新中间CA证书时才会使用。

因为是采用自签名的CA根证书给服务器端证书签名,因此需要生成服务器端的证书和证书请求文件。

服务器端的证书和证书请求文件操作如下:

【工作目录为/root/server-cert-temp】

1
[root@support ~]$mkdir -p /root/server-cert-temp

6.1 生成服务端私钥

1
2
3
4
[root@support ~]$openssl genrsa -out /root/server-cert-temp/cert.key 2048

# 对于有密码要求的,例如华为防火墙USG系列
[root@support ~]$openssl genrsa -aes256 -out private/cakey.pem 2048

6.2 生成证书请求文件

1
2
3
4
openssl req -new \
-key /root/server-cert-temp/cert.key \
-out /root/server-cert-temp/cert.csr \
-subj "/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=cp4d-cpd-cp4d.apps.openshift4.cj.io/emailAddress=zhangcheng@cj.com.cn"

6.3 使用CA根证书签发服务端证书

【这里有很多种方法,前两种方法】

【SSL证书在有效期的控制上更为严格,目前SSL证书的有效期最长时间为 27 个月,【准确来说是825天】。

所以当您网站部署的SSL证书已经过期的时候,浏览器也会提示网站“SSL证书不可信”。】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201026082847534.png

【关于:为解决谷歌浏览器不能识别证书通用名称NET::ERR_CERT_COMMON_NAME_INVALID错误】

即提示安全证书没有制定主题主备名称。

【本质原因是】

Google Chrome在4月24日发布的Chrome58做了SSL安全相关的变动,58之前版本Chrome 支持检查SSL证书对域名生效的“通用名称”字段。从Chrome 58开始,只通过校验SAN属性验证证书的有效性。

Chrome在长达数年的努力后终于取消了对通用名检查的支持。

包含着SSL证书是否对某域名生效的“通用名称”字段,早在二十年前就被RFC淘汰了。取而代之的应该是SAN(主题备用名称)字段。

此更改只会影响私有PKI和其他未遵循规范的软件。

6.3.1 配置SAN

注意,这里提及了SAN属性。从Chrome 58开始,只通过校验SAN属性验证证书的有效性。

SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 SSL 证书,可以扩展此证书支持的域名,使得一个证书可以支持多个不同域名的解析。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/a46bb7729650a0bfebc19ecc23fa77ff.png

对于 Google 这种域名数量较多的公司来说,使用这种类型的证书能够极大的简化网站证书的管理。

如何设置SAN属性,首先需要添加扩展文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
[root@support server-cert-temp]$vi /etc/pki/tls/openssl.cnf

# 具体内容如下:
[ v3_req ]
extendedKeyUsage=serverAuth
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1=cp4d-cpd-cp4d.apps.openshift4.cj.io
DNS.2=www.cp4d-cpd-cp4d.apps.openshift4.cj.io
# 如果是IP地址类
IP.1 =172.18.1.30
IP.2 =172.18.1.31

【重要:证书最长有效期是825天】

1
2
3
4
5
6
[root@support certifacation]$# 

# 利用CA证书签名
openssl x509 -req -days 825 -sha256 -extensions v3_req -extfile /etc/pki/tls/openssl.cnf \
-CA /etc/pki/CA/certs/ca.crt -CAkey /etc/pki/CA/private/ca.key \
-CAserial ca.srl -CAcreateserial -in cert.csr -out cert.crt

在x509指令中,有多重方式可以指定一个将要生成证书的序列号,可以使用set_serial选项来直接指定证书的序列号,也可以使用-CAserial选项来指定一个包含序列号的文件。所谓的序列号是一个包含一个十六进制正整数的文件,在默认情况下,该文件的名称为输入的证书名称加上.srl后缀,比如输入的证书文件为ca.cer,那么指令会试图从ca.srl文件中获取序列号,可以自己创建一个ca.srl文件,也可以通过-CAcreateserial选项来生成一个序列号文件。

-extensions表示扩展属性 -extfile表示扩展属性所在的文件

会在当前路径创建ca.srl 序列文件

1
2
[root@support certifacation]$ll ca.srl
-rw-r--r--. 1 root root 17 Oct 19 12:35 ca.srl

6.3.2 验证SAN

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Authority Key Identifier:
            DirName:/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=ca.cj.io/emailAddress=zhangcheng@cj.com.cn
            serial:FA:4E:9B:47:40:48:C5:7D

        X509v3 Basic Constraints:
            CA:FALSE
        X509v3 Key Usage:
            Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
#  可以看到这里的Subject Alternative Name
        X509v3 Subject Alternative Name:
            DNS:vcenter7.vmware.cj.io, DNS:firewall1.server.cj.io, IP Address:192.168.100.250, IP Address:58.33.40.242
Signature Algorithm: sha256WithRSAEncryption
     26:ee:d5:93:8e:4b:be:4c:c7:9f:2d:29:fb:9c:a8:24:bd:83:
     fc:f1:03:44:54:fb:04:09:ad:50:11:b9:a6:10:78:ef:c9:8f:

6.3.3 秘钥用法说明

前述SAN扩展文件中有一些参数,解释如下:

数字签名 :digitalSignature

认可签名 :nonRepudiation

密钥加密 :keyEncipherment

数据加密:dataEncipherment

代码签名:codeSigning

密钥协商:keyAgreement

时间戳:timeStamping

安全电子邮件 (S/MIME):emailProtection

SSL / TLS Web客户端身份验证:clientAuth

SSL / TLS Web服务器身份验证:serverAuth

6.4 可能出现的问题

在最终浏览器验证环节,会提示错误

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024111532283.png

但是用IE缺不会出现问题

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024123723773.png

【解决方法】

需要配置SAN。

【注意需要采用sha256,如果采用sha1,谷歌浏览器会提示错误】

【具体提示错误:但是服务器出示的证书是使用弱签名算法(例如 SHA-1)签署的。这意味着服务器出示的安全凭据可能是伪造的,因此这可能并不是您想要访问的服务器(您可能正在与攻击者进行通信)】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024131141160.png

【解决方法】

指定sha256

7.部署根证书

win+R,输入【certmgr.msc】

打开证书管理器

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024111204417.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024111217600.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024111231809.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024111250090.png

8.案例1《部署IBM CP4D》

这里通过一个IBM CP4D的系统来描述自定义TLS证书的过程。

8.1 部署已生成的TLS证书

刚部署完毕的TLS证书是不安全的。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201023083326574.png

【第一步:准备证书和专用密钥文件】

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# 进入临时工作目录
cd /root/server-cert-temp
# 生成服务器秘钥
openssl genrsa -out /root/server-cert-temp/cert.key 2048
# 生成服务器证书请求
openssl req -new -key cert.key -out cert.csr \
-subj "/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=cp4d-cpd-cp4d.apps.openshift4.cj.io/emailAddress=zhangcheng@cj.com.cn"

# 配置extfile
vi /etc/pki/tls/openssl.cnf

[ alt_names ]
DNS.1=cp4d-cpd-cp4d.apps.openshift4.cj.io

# 利用CA证书签名
openssl x509 -req -days 825 -sha256 -extensions v3_req -extfile /etc/pki/tls/openssl.cnf \
-CA /etc/pki/CA/certs/ca.crt -CAkey /etc/pki/CA/private/ca.key \
-CAserial ca.srl -CAcreateserial -in cert.csr -out cert.crt
# 最终得到cert.crt和cert.key

【第二步:部署】

必要的证书作为连接到集群的客户机上的可信证书。专用密钥名为 cert.key,已生成的证书文件为cert.crt 。

  1. 将 cert.crt 和 cert.key 文件置于本地文件系统的同一目录中。

  2. 切换到这些文件所在目录。

  3. 连接到 OpenShift 集群:

    1
    
    oc login OpenShift_URL:port
    
  4. 将上下文(project)设置为部署 Cloud Pak for Data 的项目:

    1
    
    oc project cp4d
    
  5. 找到部署中的 ibm-nginx pod:

    1
    2
    
    ibm_nginx_pod=$(oc get pods | grep ibm-nginx | head -1 | cut -f1 -d\ )
    echo $ibm_nginx_pod
    
  6. 在 pod 的 user-home/global 目录中创建名为 customer-certs 的目录:

    1
    2
    
    oc exec ${ibm_nginx_pod} -- rm -rf "/user-home/_global_/customer-certs"
    oc exec ${ibm_nginx_pod} -- mkdir -p "/user-home/_global_/customer-certs"
    
  7. 将证书和密钥文件复制到 customer-certs 目录:

    1
    2
    3
    4
    
    oc cp cert.crt ${ibm_nginx_pod}:/user-home/_global_/customer-certs/
    oc cp cert.key ${ibm_nginx_pod}:/user-home/_global_/customer-certs/
    
    oc exec ${ibm_nginx_pod} -- ls -p "/user-home/_global_/customer-certs"
    
  8. 重新启动所有 ibn-nginx pod:

    1
    
    for i in `oc get pods | grep ibm-nginx |  cut -f1 -d\ `; do oc exec ${i} -- /scripts/reload.sh; done
    

【部署完毕后验证】

8.2 最终验证

通过导入自定义根证书,并且通过章节7中的方法进行服务器证书签名。通过谷歌浏览器进行方法,证书有效。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024132422570.png

【最终正确的证书显示结果如下】

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024132517383.png

签名哈希算法为256

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201024132549416.png

这里就是文件SAN属性,这里我设置了DNS.1和IP.1

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201111202421144.png

9.案例2《部署VCenter 7中的自定义TLS证书》

包括服务器证书和根证书

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201019082433976.png

从VCenter服务器查看,服务器证书具体如下:

../../../../Downloads/image-20201019082305789.png

浏览器访问,可以看到,信息一致

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201019082455154.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201019082507218.png

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201019082516198.png

可以使用企业或第三方 CA 的自定义证书。第一步是向证书颁发机构请求证书并将根证书导入 VMware 端点证书存储 (VECS)。

9.1 前提条件

证书必须满足以下要求:

  • 密钥大小:2048 位(最小值)到 16384 位(最大值)(PEM 编码)
  • PEM 格式。VMware 支持 PKCS8 和 PKCS1(RSA 密钥)。密钥添加到 VECS 后,会转换为 PKCS8。
  • x509 版本 3
  • 对于根证书,CA 扩展必须设置为 true,并且 cert 签名必须在要求列表中。
  • SubjectAltName 必须包含 DNS Name=<machine_FQDN>。
  • CRT 格式
  • 包含以下密钥使用:数字签名、不可否认性、密钥加密(Digital Signature, Non-Repudiation, Key Encipherment)
  • 比当前时间早一天的开始时间。
  • CN(和 SubjectAltName)设置为 vCenter Server清单中的 ESXi 主机的主机名(或 IP 地址)。

9.2 更换域名访问

需要对Vcenter的访问采用域名访问方式

通过浏览器访问https://Vcenter:5480

进入网络,点击编辑

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201105123812469.png

按照提示,编辑正确的域名地址。

【其中DNS可以选择外部DNS,或者本地127.0.0.1,如果选择后者注意更新本地vcenter的hosts文件】

随后Vcenter进行重启

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201105110205405.png

重新登录后,网络继续更新。

https://typorabyethancheung911.oss-cn-shanghai.aliyuncs.com/typora/image-20201105110822816.png

【登录后,如果提示No Healthy Upstream】

【解决办法,利用SSH登录Vcenter,新增一条记录127.0.0.1 vcenter7.vmware7.cj.io localhost】

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
root@vcenter7 [ ~ ]# vi /etc/hosts
root@vcenter7 [ ~ ]# cat /etc/hosts

# Begin /etc/hosts (network card version)

192.168.100.250 vcenter7.vmware7.cj.io vcenter7
192.168.100.250 vcenter7.vmware7.cj.io vcenter7

127.0.0.1 vcenter7.vmware7.cj.io localhost

# End /etc/hosts (network card version)

9.3 具体配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# 先申请秘钥
[root@support ~]$cd /root/server-cert-temp/

[root@support ~]$openssl genrsa -out cert.key 2048


# 生成证书请求1
openssl req -new \
-key cert.key \
-out cert.csr \
-subj "/C=CN/ST=SHANGHAI/L=SH/O=CJ/OU=IT/CN=vcenter7.vmware7.cj.io/emailAddress=zhangcheng@cj.com.cn"


[root@support server-cert-temp]$vi http.ext 

# 具体内容如下:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = vcenter7.vmware7.cj.io
IP.1 = 192.168.100.250
IP.2 = 192.168.100.41
IP.3 = 192.168.100.42
IP.4 = 192.168.100.43



[root@support ~]$openssl x509 -req -days 825 -sha256 -extensions v3_req -extfile /etc/pki/tls/openssl.cnf \
-CA /etc/pki/CA/certs/ca.crt -CAkey /etc/pki/CA/private/ca.key \
-CAserial ca.srl -CAcreateserial -in cert.csr -out cert.crt -extfile http.ext


# 验证
openssl x509 -noout -text -in cert.crt

8e:8e:ef:f5:fa:8a:bd:27

9.4 可能出现的问题

访问vCenter 7 如果出现 “No Healthy Upstream”错误,需要SSH登录到vCenter,配置/etc/hosts

1
2
3
4
5
6
7
8
9
root@vcenter7 [ ~ ]# vi /etc/hosts

# Begin /etc/hosts (network card version)

192.168.100.250 vcenter7.vmware.cj.io vcenter7
192.168.100.250 vcenter7.vmware.cj.io vcenter7
127.0.0.1 vcenter7.vmware.cj.io localhost

# End /etc/hosts (network card version)

10.转换证书格式

openssl默认使用PEM格式(形如—–BEGIN CERTIFICATE—– … … —–END CERTIFICATE—)存放证书和私钥,nginx/node.js可以使用该格式启动服务。

但使用tomcat或java客户端/android时,不能使用该格式的证书。jdk中包含了一个keytool命令,可以完成整个的证书生成过程,不过这里我们只用openssl工具也可以完成java的支持,即使用PKCS12格式对证书进行打包。

PKCS12格式文件,可以包含多个证书/私钥对,指定多个受信任的server(也可以不包含证书),每个server有一个alias name。我们来看最简单的只包含一个alias的文件生成:

1
openssl pkcs12 -export -in sign.crt -inkey sign.key -out sign.p12

上面的命令将CA证书及其私钥导出为sign.p12文件,导出时需要指定一个密码。

11.吊销证书

当证书已经不再使用或者密钥泄露时,我们需要吊销证书来保证服务器的安全。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#获取要吊销的证书的serial
openssl x509 -in /path/to/x.crt -noout -serial -subject

#对比serial与subject 信息是否与index.txt中的信息一致
#如果一致,则可以吊销证书
openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem

#如果是第一次吊销证书,需要指定吊销的证书编号
echo 01 >/etc/pki/CA/crlnumber

#更新吊销证书列表
openssl ca -gencrl -out /etc/pki/CA/crl.pem

#完成后,可查看吊销的证书列表
openssl crl -in /etc/pki/CA/crl.pem -noout -text

12.相关查看命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# 查看私钥信息
openssl rsa -noout -text -in server.key 
#  查看签名请求信息
openssl req -noout -text -in server.csr 
#   查看证书信息
openssl x509 -noout -text -in ca.crt  
# 查看一个证书吊销列表信息
openssl crl -text -in xx.crl  
# 查看一个证书的额外信息
openssl x509 -purpose -in cacert.pem  
# 从一个私钥里面提取出公钥
openssl rsa -in key.pem -pubout -out pubkey.pem 
# 查看一个公钥的信息
openssl rsa -noout -text -pubin -in apache.pub  
# 验证一个证书是否是某一个CA签发
openssl verify  -CAfile  指定CA文件路径  apache.crt  

by 张诚 2020.11.11