一. TLS概述

1. TLS概述

1. TLS 握手的作用之一是身份认证），被验证的一方需要提供一个身份证明。在 HTTPS 的世界里，这个身份证明就是 「TLS 证书」，或者称为 「HTTPS 证书」。

   • 例如，我们在访问 https://www.youzan.com 时，浏览器会得到一个 TLS 证书，这个数字证书用于证明我们正在访问的网站和证书的持有者是匹配的，否则因为身份认证无法通过，连接也就无法建立。
     

   • 浏览器得到的是一个证书的链表，这个链表叫证书链（Certificate Chain）。

2. HTTPS 协议栈与 HTTP 的唯一区别

• HTTPS 多了一个安全层（Security Layer），即 TLS/SSL 。
• SSL 是最早的安全层协议， TLS 由 SSL 发展而来，下面我们统称 TLS 。
  

3. TLS协议版本

• OkHttp是android端最火热的一个轻量级框架，用于替代HttpUrlConnection和Apache HttpClient。
• 它用一个 enum 类型来表示 TLS 协议的不同版本。可以看到最早的版本是 SSLv3，诞生于 1996 年，最新的版本是 TLSv1.3。

public enum TlsVersion {
	  TLS_1_3("TLSv1.3"), // 2016. （最新的版本）
	  TLS_1_2("TLSv1.2"), // 2008.
	  TLS_1_1("TLSv1.1"), // 2006.
	  TLS_1_0("TLSv1"),   // 1999.
	  SSL_3_0("SSLv3"),   // 1996.（最早的版本）
	  ;
	  final String javaName;
}

二. TLS证书格式

1. 概述

1. 所有 CA 机构会遵守 X.509 规范来签发公钥证书（Public Key Certificate），证书内容的语法格式遵守 ASN.1，证书大致包含如下内容：
   
2. Certificate Issuer表示证书的签发者/颁发者。如访问网址 https://www.youzan.com 的[*.youzan.com]证书，它的签发者是它的父节点[GeoTrust RSA CA 2018]。Issuer字段的内容是一组符合X.500规范的DN（Distinguished Name），其中DN是由逗号连接的相对专有名称（RDN，relative distinguished names）的序列。Issuer通常表示为：

Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=GeoTrust RSA CA 2018

2. 示例：知乎网站证书解析(mac系统)

1. 从浏览器导出网站的HTTPS证书到本地文件夹，网址为https://link.zhihu.com/?target=https%3A//www.youzan.com/。具体步骤，windows系统可以按照教程 （如何从浏览器导出HTTPS证书）完成，mac系统目前不知道如何导出。
2. 将导出的证书文件拖入「Keychain Access」。
   
3. 从 「Keychain Access」中导出证书，格式选择 pem。
   

-证书导出包含四种格式。但不知道为什么我导出的cer文件格式openssl解析失败。

证书：Certificate (.cer)
增强保密邮件：Privacy Enhanced Mail (.pem)
证书包Certificate Bundle (.p7b)
个人信息交换：Personal Information Exchange (.p12)

4. 在terminal通过openssl命令查看证书内容

openssl x509 -in /Users/zijikanwa/*.zhihu.com.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0e:3c:c1:49:94:b3:e1:74:a6:34:54:d9:90:64:66:d7
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=GeoTrust RSA CA 2018
        Validity
            Not Before: Dec 25 00:00:00 2017 GMT
            Not After : Dec 24 12:00:00 2020 GMT
        Subject: C=CN, L=\xE5\x8C\x97\xE4\xBA\xAC\xE5\xB8\x82, O=\xE6\x99\xBA\xE8\x80\x85\xE5\x9B\x9B\xE6\xB5\xB7\xEF\xBC\x88\xE5\x8C\x97\xE4\xBA\xAC\xEF\xBC\x89\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, OU=IT, CN=*.zhihu.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a0:a8:71:88:cf:5e:1b:e6:c8:45:ed:60:89:ce:
                    d2:76:a0:af:03:a6:c1:18:bb:8c:8c:c7:cb:b6:93:
                    ce:46:4f:46:74:66:49:1a:80:2c:ae:4f:1b:db:c1:
                    5c:8d:ad:b6:23:06:dc:97:c0:d0:c4:7d:a9:f8:4e:
                    79:e4:b4:d1:ed:41:c3:52:87:6c:ac:f3:05:86:5f:
                    57:52:a0:d2:93:34:7c:6f:d5:4e:21:c4:7c:5b:be:
                    6f:b0:3e:ef:6c:4c:8f:90:f7:ae:50:c9:a0:b7:dd:
                    42:eb:c2:c0:58:0e:da:65:01:be:c1:43:6e:2f:f2:
                    59:fd:b6:c4:59:1f:cd:ee:af:55:44:06:c4:8b:6e:
                    b8:f7:1a:e1:ad:89:4a:0a:a2:9c:a3:a8:bc:65:41:
                    f3:7d:e0:29:03:fb:84:a3:da:7b:fb:c9:ec:87:aa:
                    87:5c:58:02:0e:02:d8:c1:cf:b1:1c:25:f7:df:ac:
                    0a:a6:7b:c5:5d:d0:51:e2:97:c6:ff:01:17:21:a6:
                    c0:fd:88:b1:a6:2d:aa:d0:4f:61:3c:35:13:dc:ff:
                    51:ce:2d:48:18:c3:cd:05:43:60:e2:9a:4c:01:55:
                    98:31:9d:f3:c4:4b:3b:49:17:d4:bd:0b:34:e1:24:
                    05:a7:48:87:49:69:77:76:d0:d3:f2:70:f2:e7:c0:
                    90:b1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:90:58:FF:B0:9C:75:A8:51:54:77:B1:ED:F2:A3:43:16:38:9E:6C:C5

            X509v3 Subject Key Identifier: 
                31:63:1F:A1:0B:43:D7:A5:8C:3D:F6:2E:85:69:D4:E1:E3:56:91:46
            X509v3 Subject Alternative Name: 
                DNS:*.zhihu.com, DNS:zhihu.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://cdp.geotrust.com/GeoTrustRSACA2018.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.114412.1.1
                  CPS: https://www.digicert.com/CPS
                Policy: 2.23.140.1.2.2

            Authority Information Access: 
                OCSP - URI:http://status.geotrust.com
                CA Issuers - URI:http://cacerts.geotrust.com/GeoTrustRSACA2018.crt

            X509v3 Basic Constraints: 
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
         54:73:e6:02:db:5d:49:30:4d:61:71:ac:ef:6d:f1:52:af:45:
         f2:0f:81:94:0b:5c:0e:bd:b6:c2:98:af:08:6c:11:45:25:e9:
         8d:7d:80:d8:3e:78:50:5d:f8:4d:bf:ef:6d:fd:8a:74:d9:6c:
         90:65:55:b6:d1:59:3a:07:25:42:6a:74:b0:dd:31:e2:a0:50:
         04:4a:03:fe:61:24:e7:74:33:c9:69:94:70:79:d9:89:20:c3:
         80:b2:e7:73:72:b6:73:00:10:8f:8e:25:0e:1f:41:b6:bc:86:
         da:d2:b4:ae:c7:b9:1d:80:fa:58:e7:ba:79:2c:ef:63:5a:96:
         af:03:22:98:78:58:57:9f:70:45:a3:0a:22:87:c3:ef:45:7d:
         2a:ed:d8:1b:38:2e:9e:d7:27:7e:53:d1:44:62:3d:cb:d0:e6:
         01:e6:3a:5c:86:8c:d5:b8:91:4c:d8:55:07:e6:23:03:71:23:
         ce:19:f6:4e:a4:ba:69:55:eb:d9:11:49:32:09:ee:b8:58:43:
         69:ff:51:6b:c6:17:7f:74:83:50:19:a0:99:79:64:6a:e0:ff:
         5b:f5:51:53:fb:22:3a:10:a4:4f:ed:25:b2:ca:cb:8a:1b:1e:
         bc:db:5d:46:95:31:fe:03:c8:cc:42:dc:b6:e4:29:d9:85:f9:
         6a:4e:39:d8
-----BEGIN CERTIFICATE-----
MIIFCTCCA/GgAwIBAgIQDjzBSZSz4XSmNFTZkGRm1zANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRHZW9UcnVzdCBSU0EgQ0EgMjAxODAe
Fw0xNzEyMjUwMDAwMDBaFw0yMDEyMjQxMjAwMDBaMHkxCzAJBgNVBAYTAkNOMRIw
EAYDVQQHDAnljJfkuqzluIIxMzAxBgNVBAoMKuaZuuiAheWbm+a1t++8iOWMl+S6
rO+8ieaKgOacr+aciemZkOWFrOWPuDELMAkGA1UECxMCSVQxFDASBgNVBAMMCyou
emhpaHUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoKhxiM9e
G+bIRe1gic7SdqCvA6bBGLuMjMfLtpPORk9GdGZJGoAsrk8b28Fcja22Iwbcl8DQ
xH2p+E555LTR7UHDUodsrPMFhl9XUqDSkzR8b9VOIcR8W75vsD7vbEyPkPeuUMmg
t91C68LAWA7aZQG+wUNuL/JZ/bbEWR/N7q9VRAbEi2649xrhrYlKCqKco6i8ZUHz
feApA/uEo9p7+8nsh6qHXFgCDgLYwc+xHCX336wKpnvFXdBR4pfG/wEXIabA/Yix
pi2q0E9hPDUT3P9Rzi1IGMPNBUNg4ppMAVWYMZ3zxEs7SRfUvQs04SQFp0iHSWl3
dtDT8nDy58CQsQIDAQABo4IBpjCCAaIwHwYDVR0jBBgwFoAUkFj/sJx1qFFUd7Ht
8qNDFjiebMUwHQYDVR0OBBYEFDFjH6ELQ9eljD32LoVp1OHjVpFGMCEGA1UdEQQa
MBiCCyouemhpaHUuY29tggl6aGlodS5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA+BgNVHR8ENzA1MDOgMaAvhi1odHRw
Oi8vY2RwLmdlb3RydXN0LmNvbS9HZW9UcnVzdFJTQUNBMjAxOC5jcmwwTAYDVR0g
BEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGln
aWNlcnQuY29tL0NQUzAIBgZngQwBAgIwdQYIKwYBBQUHAQEEaTBnMCYGCCsGAQUF
BzABhhpodHRwOi8vc3RhdHVzLmdlb3RydXN0LmNvbTA9BggrBgEFBQcwAoYxaHR0
cDovL2NhY2VydHMuZ2VvdHJ1c3QuY29tL0dlb1RydXN0UlNBQ0EyMDE4LmNydDAJ
BgNVHRMEAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBUc+YC211JME1hcazvbfFSr0Xy
D4GUC1wOvbbCmK8IbBFFJemNfYDYPnhQXfhNv+9t/Yp02WyQZVW20Vk6ByVCanSw
3THioFAESgP+YSTndDPJaZRwedmJIMOAsudzcrZzABCPjiUOH0G2vIba0rSux7kd
gPpY57p5LO9jWpavAyKYeFhXn3BFowoih8PvRX0q7dgbOC6e1yd+U9FEYj3L0OYB
5jpchozVuJFM2FUH5iMDcSPOGfZOpLppVevZEUkyCe64WENp/1Frxhd/dINQGaCZ
eWRq4P9b9VFT+yI6EKRP7SWyysuKGx68211GlTH+A8jMQty25CnZhflqTjnY
-----END CERTIFICATE-----

3. 通过openssl获取证书的含义

1. 一个 证书（Certificate） 由 数据（Data） 和 签名（Signature） 两部分组成。
2. 数据（Data）包含内容如下：
   • 证书版本号（Version）：X.509v3
   • 序列号（Serial Number）：一个 CA 机构内是唯一的，但不是全局唯一
   • 签名算法（Signature Algorithm）：签名的计算公式为RSA(sha256(Data), IssuerPrivateKey)
   • 签发者（Issuer）：DN（Distinguished Name）
   • 有效期（Validity）：证书的有效期间 [Not Before, Not After]
   • 证书拥有者（Subject）：也是一个 DN公钥长度一般是 2048bit，1024bit已经被证明不安全
   • 扩展字段（X509v3 extensions）：证书所携带的域名信息会配置在 SAN 中（X509v3 Subject Alternative Name）
3. 签名（Signature）：位于证书最末尾，签名算法 sha256WithRSAEncryption 在 Data 域内已经指明 ，而 RSA 进行非对称加密所需的私钥（Private Key）是由 Issuer 提供。
   • Issuer 是一个可以签发证书的证书，由证书权威 CA 提供，CA 需要保证证书的有效性，而且 CA 的私钥需要绝密保存，一旦泄露出去，证书可能会被随意签发。
   • 生成签名的公式：Signature = RSA(sha256(Data), IssuerPrivateKey)

三. 证书链（Certificate Chain）

1. 背景

• UA（如客户端/浏览器）拿到TLS证书之后，需要Issuer的公钥（Public Key）才能解码出Data的信息摘要。但是证书只携带了Issuer的DN，并没有公钥，那客户端是如何获取到公钥的？
  

2. 概述

• X.509 除了规范证书的内容之外，还规范了如何获取 CRL 以及 证书链（Certificate Chain） 的验证算法。

3. 背景问题的解释

1. 在访问网址（https://www.youzan.com）时，浏览器并非只拿到一个证书，而是一个证书链：

DigiCert Global Root CA
	|__  GeoTrust RSA CA 2018
		|__  *.zhihu.com

2. 证书「*.zhihu.com」的 签发者（Issuer）就是它的父节点「GeoTrust RSA CA 2018」。因为 UA（浏览器或操作系统）中会预先内置一些权威 CA签发的根证书（Root Certificate）或中间证书（Intermediate Certificate），例如上面的 「GeoTrust RSA CA 2018」和 「DigiCert Global Root CA」。
   

3. 当获得证书链之后，我们就可以很轻松的往上回溯到被 UA 信任的证书，虽然 UA 内置的可能是中间证书（Intermediate Certificate）。

4. 但是如果一个 End-Entity 证书即使回溯到跟证书（Root Certificate）也没有在 UA 的受信列表中找到，那么这个站点就会被标记为不安全。例如 12306 的主页被标记为 “Not Secure"，因为它的根证书不被信任。
   

参考资料

• HTTPS 精读之 TLS 证书校验

希望在生成 SSL/TLS 证书之前，您已经安装有 openssl 以及对 SSL/TLS 有了初步的了解。

概述

本文主要讲述CA的私钥和x509自签名证书的生成，服务器/客户端的私钥和CSR的生成，以及CA对服务器/客户端的CSR签名操作。初始文件包括server-ext.cnf、client-ext.cnf以及gen.sh，相关内容如下：

server-ext.cnf

subjectAltName=DNS:*.study.com,DNS:*.study.org,IP:0.0.0.0

client-ext.cnf

subjectAltName=DNS:*.client.com,DNS:*.client.org,IP:0.0.0.0

gen.sh

rm *.pem

# 1.生成CA的私钥和自签名证书
openssl req -x509 -newkey rsa:4096 -days 365 -nodes -keyout ca-key.pem -out ca-cert.pem -subj "/C=CH/ST=SiChuan/L=ChengDu/O=Study/OU=Go/CN=Tony/emailAddress=Tony@email.com"

echo "CA's self-signed certificate"
openssl x509 -in ca-cert.pem -noout -text

# 2.生成服务器的私钥和证书签名请求(CSR)
openssl req -newkey rsa:4096 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=CH/ST=GuangDong/L=GuangZhou/O=Computer/OU=Go/CN=Harry/emailAddress=Harry@email.com"

# 3.使用CA的私钥签署服务器的CSR并生成签名证书
openssl x509 -req -in server-req.pem -days 60 -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile server-ext.cnf

echo "Server's certificate signed by CA"
openssl x509 -in server-cert.pem -noout -text

echo "Verify ca-cert.pem server-cert.pem"
openssl verify -CAfile ca-cert.pem server-cert.pem

# 4.生成客户端的私钥和证书签名请求(CSR)
openssl req -newkey rsa:4096 -nodes -keyout client-key.pem -out client-req.pem -subj "/C=CH/ST=FuJian/L=XiaMen/O=Client/OU=Gopher/CN=Alice/emailAddress=Alice@email.com"

# 5.用CA的私钥签署客户端的CSR并生成签名证书
openssl x509 -req -in client-req.pem -days 60 -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -extfile client-ext.cnf

echo "client's certificate signed by CA"
openssl x509 -in client-cert.pem -noout -text

echo "Verify ca-cert.pem client-cert.pem"
openssl verify -CAfile ca-cert.pem client-cert.pem

运行结果

• ca-key.pem：CA的私钥
• ca-cert.pem：CA的证书文件。
• ca-cert.srl：保存证书的唯一序列号。
• client-ext.cnf：客户端证书扩展信息。
• client-req.pem：客户端的证书签名请求（CSR）文件。
• client-key.pem：客户端的私钥。
• client-cert.pem：客户端的证书。
• server-ext.cnf：服务器证书扩展信息。
• server-req.pem：服务器的证书签名请求（CSR）文件。
• server-key.pem：服务器的私钥。
• server-cert.pem：服务器的证书。

后面将逐个讲解gen.sh中的相关命令。

一. 生成CA的私钥和自签名证书

openssl req -x509 -newkey rsa:4096 -days 365 -nodes -keyout ca-key.pem -out ca-cert.pem -subj "/C=CH/ST=SiChuan/L=ChengDu/O=Study/OU=Go/CN=Tony/emailAddress=Tony@email.com"

• req -x509：输出X509格式的自签名证书。
• -newkey rsa:4096：输出4096位的RSA格式的私钥。
• -days 365：证书有效期为365天。
• -nodes：不进行对私钥的加密。
• -keyout ca-key.pem：将私钥写入ca-key.pem文件中。
• -out ca-cert.pem：将签名证书写入ca-cert.pem文件中。
• -subj：身份信息。

-nodes 与 -subj

为了便于理解，这里将 -nodes、-subj 选项去除后得到命令：

openssl req -x509 -newkey rsa:4096 -days 365 -keyout ca-key.pem -out ca-cert.pem

运行结果：

（如上图所示）在我们运行命令之后，因为没有 -nodes 选项，所以我们需要在A处填写私钥的密码，防止黑客盗取私钥后，若无密码则无法直接使用私钥，而需再次对私钥解密；因为没有 -subj 选项，所以我们需要在B处填写相关的身份信息，包括国家、公司等信息。

使用命令 openssl x509 -in ca-cert.pem -noout -text 查看证书信息：

因为这是自签名证书，所以 Issuer 和 Subject 的信息是相同的，Issuer为证书颁发者信息，Subject为证书拥有者信息。在后面 server 的证书中我们将会看到，这两个信息不是相同的。

若在测试环境下不想对私钥进行加密，则加上 -nodes 选项。

若不想每次都输入身份信息，则可以在首次生成证书后，将 Subject 后的信息copy下来，然后使用 -subj 选项直接带上身份信息，这里需要注意：每条信息之间需要用 “/” 间隔，以及删除 “=” 前后的空格。

在添加上 -nodes 与 -subj 选项后就得到了示例中完整的命令。

二. 生成服务器的私钥和CSR

openssl req -newkey rsa:4096 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=CH/ST=GuangDong/L=GuangZhou/O=Computer/OU=Go/CN=Harry/emailAddress=Harry@email.com"

因为这里服务器只生成CSR，所以去除 -x509 与 -days 选项，最后还需要更改下相关身份信息，运行如下：

server-key.pem：服务器的私钥。
server-req.pem：服务器证书签名请求（CSR）。

三. 使用CA 的私钥签署服务器的CSR

openssl x509 -req -in server-req.pem -days 60 -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile server-ext.cnf

• x509：x509格式的签名。
• -req -in server-req.pem：传入CSR文件server-req.pem。
• -CA ca-cert.pem：传入CA的证书文件ca-cert.pem。
• -CAkey ca-key.pem：传入CA的私钥文件ca-key.pem。
• -CAcreateserial：确保CA签署的每个证书都带有唯一的序列号，换句话说，只要是该CA签署的证书都具有唯一序号，该序号保存在 srl 文件中，若 srl 文件不存在，首次将自动生成。
• -out server-cert.pem：将CA签名后的证书内容写入server-cert.pem文件中。
• -extfile server-ext.cnf：服务器的扩展文件，其中包括DNS、IP以及Email的信息。若是需要在本地测试，则需要在 server-ext.cnf 中添加 IP:0.0.0.0，同时在客户端扩展文件（例如：client-ext.cnf）中也需要添加 IP:0.0.0.0。

运行结果：

运行后将会生成ca-cert.srl和server-cert.pem，ca-cert.crl 中保存的是该CA的唯一序列号，凡是CA所签署的证书，其 Serial Number 值将等同于 ca-cert.crl 中保留的值，如A和B的值。C 处是CA的身份信息，D 处为服务器的身份信息，E 处为证书有效期。

注意：如果我们使用的是CA加密后的私钥，则在执行上述命令时，需要输入CA私钥的密码才能对CSR进行签名。

我们可以使用 -extfile 选项，添加拓展信息，我们可以从证书文件中看到相关的拓展信息，如下：

注意：为了本地开发方便，需要在服务器的扩展文件 server-ext.cnf 中添加 IP:0.0.0.0 ，并且需要在客户端的扩展文件（例如:client-ext.cnf）中添加IP:0.0.0.0。

四. 生成客户端的私钥和CSR

openssl req -newkey rsa:4096 -nodes -keyout client-key.pem -out client-req.pem -subj "/C=CH/ST=FuJian/L=XiaMen/O=Client/OU=Gopher/CN=Alice/emailAddress=Alice@email.com"

同二。

五. 使用CA 的私钥签署客户端的CSR

openssl x509 -req -in client-req.pem -days 60 -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -extfile client-ext.cnf

同三。

#创建证书
#openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout fortune-teller.key -out fortune-teller.pem -subj "/CN=*.serving.dubhe.ai/O=*.serving.dubhe.ai"
#创建Secret
#kubectl create secret tls fortune-teller.stack.build --cert fortune-teller.pem --key fortune-teller.key -n default 

通过查看 kubectl edit secret fortune-teller.stack.build 得到证书