假设有一家银行持有大量客户资金，允许用户通过其网站onebank.com转账。现在一个黑客连接到公共wifi，并使用虚假的DHCP服务告诉WiFi上的其他用户：我是网关，让我转发你的互联网流量。这使所有用户名和密码等信息都会经过他的服务，可能出现泄露。这些信息用户虽然会使用TLS加密，但如果黑客得了颁发的证书，然后部署了一个虚假服务器并告诉用户，这个假onebank.com网站就是银行网站，这样就可以获得用户的信息。这里出现泄露问题的重点在于证书，客户信任了假服务器提供的证书。证书的作用即是证明持有者是真实、有效值得信任的。
一个常见的误解是，只有证书颁发机构才能颁发证书。事实上，任何人都可以颁发证书。可以自己创建根证书，并向任何域颁发证书。可以有许多证书，但客户端必须只信任有效的证书。什么样的证书是可以信任的有效证书？即由权威证书颁发机构 （CA） 颁发的证书。证书涉及三方：客户端、CA和网站，是相互关联的，每个参与者都有自己的职责。他们的关系是：
- 客户端信任 CA。
- CA 向网站颁发证书。
- 当客户访问网站时，该网站会出示其证书。由于客户端信任 CA，因此它也信任 CA颁发的证书。
为什么CA值得信任？证书颁发机构 （CA） 有三个主要职责：
1.对网站：当有人申请证书时，必须验证申请人的身份。如果申请者没有得到申请域名的回应，将无法向他们颁发证书。
2.对自己：保护其根证书的私钥。
3.对客户：获得信任。一切的基础是客户必须信任 CA。对所有其他证书的信任源于对 CA 根证书的信任。建立信任是一个漫长的过程。
CA不能向错误的人颁发证书，因为这将允许证书持有人冒充他人。因此，对于所有申请人，必须确保他们在颁发证书之前确实拥有对域名的控制权。这意味着要验证申请人的身份，常有的验证方式：
1）使用ACME方式，要向我（CA）证明你是你，你需要让指定URL返回特定文本来表明你对域的控制权，之后将向你颁发证书。大致流程是CA向你的 ACME 客户端提供一个令牌，然后你的 ACME 客户端将在你 Web 服务器指定路径上放置令牌文件。 该文件包含令牌以及帐户密钥的指纹。一旦你的 ACME 客户端告诉CA文件已准备就绪，CA会尝试获取它（可能从多个地点进行多次尝试）。 如果验证机制在你的 Web 服务器上找到了放置于正确地点的正确文件，则该验证被视为成功，你可以继续申请颁发证书。
2）另一种方法，例如 DNS TXT记录。此验证方式要求你在该域名下的 TXT 记录中放置特定值来证明你控制域名的 DNS 系统。 需要在域名的DNS解析服务商手动修改域名的DNS解析记录，在解析记录中添加一条用于验证的记录。CA验证添加的记录能被解析，则表示验证通过,可以颁发证书。
CA 必须保护他们的私钥，将其通过多种安全措施存储。因为如果它被泄露，他就无法再履行其职责。持有泄露密钥的人可以随意颁发证书。这对于 CA来说将是灾难性的问题。CA颁发的所有证书都需要被吊销，网站需要重新部署新证书，如果客户端不及时吊销的被泄露的CA证书，他们可能面临访问欺诈性服务器的风险。为了应对泄露问题，根证书通常不会直接颁发网站证书。 因为需要证书的网站众多（包括过期时重新颁发），CA从安全存储库中访问证书的私钥效率非常低。为了解决这个问题，它颁发中间证书，然后用于向网站颁发证书。
为了完成上面的工作，提出了信任链，既如果客户端信任 CA，则客户端应信任 CA 颁发的证书，并且应信任这些证书颁发的证书，依此类推。这是否意味着任何人都可以利用 CA 的可信度来颁发证书。例如使用CA颁发给我的证书来颁发其他证书？这当然不能。CA 颁发的证书包含一个字段"X509v3 Basic Constraints: critical CA:FALSE"。通过下载一个网站的证书并使用 OpenSSL 工具进行解析，会看到在此证书链中，根证书和中间证书都有"CA：TRUE"，而网站使用的域名证书是 “CA：FALSE”。可以修改此字段以颁发证书吗？当然，但修改后的证书将不再受信任。
首先，客户端必须沿着证书链验证到最终root证书。每个步骤都必须确认已验证的证书是有效的。每个证书都指定了颁发者。什么是有效的CA证书？
1.证书不得过期。
2.使用颁发者（通常是根CA或另一个中间CA）的公钥来验证中间CA证书上的数字签名正确。
3.颁发者必须是 CA：TRUE。
涉及的字段是X.509标准v3证书的属性字段，证书的属性字段如下：
Certificate:
Data:
Version: 3 (0x2) //X.509标准的版本
Serial Number: //证书的唯一标识符
eb:cb:c6:2a:19:9f:25:9e:47:12:e6:3d:22:8e:bf
Signature Algorithm: sha256WithRSAEncryption //签名算法
Issuer: CN=tet //颁发此证书的实体
Validity //生效时间与失效时间
Not Before: Aug 5 12:51:09 2024 GMT
Not After : Aug 12 12:51:09 2024 GMT
Subject: CN=tet //主题信息
Subject Public Key Info:
Public Key Algorithm: rsaEncryption //公钥算法
Public-Key: (2048 bit)
Modulus: //公钥的模数值
00:a4:4e:38:9b:95:cd:1f:0a:07:7b:76:69:57:ea:
6a:f0:4a:87:d7:5c:a4:c5:e4:5c:8b:67:93:a4:9f:
b2:5d:f7:08:17:85:2e:08:9e:0e:a8:6a:29:8d:6b:
cb:09:24:fe:a3:86:08:4f:67:e9:c0:a6:24:17:34:
71:e1:9e:5b:83:47:f4:27:0a:43:ab:14:0d:66:ef:
ff:90:4d:82:3b:3e:f6:12:f8:62:d2:a9:b7:5d:5f:
dd:5b:6a:71:f7:68:65:7d:7f:a7:b8:15:f9:b1:0e:
99:1b:d5:b8:2c:10:05:e0:c7:ad:a5:6f:3f:46:c6:
c6:35:ed:fb:3b:71:fb:e2:92:5c:db:08:10:76:b9:
0d:f2:a8:db:53:dd:b8:f3:95:4a:c9:65:1f:49:3e:
6a:93:85:ce:3e:c5:60:28:15:f3:94:62:14:56:9e:
ed:ef:70:d0:a6:95:83:9d:43:52:ae:e2:29:84:94:
8a:7c:2e:99:b1:ba:dc:62:26:f5:f6:af:06:db:f2:
77:80:dc:f9:7f:10:50:cf:d1:04:16:07:c4:9b:2e:
44:e6:6f:55:c5:3e:cd:70:81:d2:07:ae:19:46:bb:
ce:ff:20:7f:87:99:86:76:21:9a:4c:ce:65:ed:9a:
05:c3:01:79:e9:e8:1b:dd:9a:b6:fa:6f:15:aa:57:
77:db
Exponent: 65537 (0x10001) //公钥的指数值
X509v3 extensions:
X509v3 Subject Key Identifier:
2C:6C:C1:90:8D:C3:E3:83:B3:65:AB:49:4D:DB:A0:16:DF:B1:BC:3F
X509v3 Key Usage: critical //密钥通途
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Basic Constraints: critical
CA:FALSE //指示证书是否是一个证书机构
X509v3 Extended Key Usage: //指定公钥的额外用途
TLS Web Client Authentication, TLS Web Server Authentication, Code Signing, E-mail Protection, Time Stamping
X509v3 Authority Key Identifier:
keyid:2C:6C:C1:90:8D:C3:E3:83:B3:65:AB:49:4D:DB:A0:16:DF:B1:BC:3F
Signature Algorithm: sha256WithRSAEncryption //签名算法
32:e3:fe:08:c2:ad:45:81:b2:37:f8:01:8e:b6:ea:a8:fa:ac: //签名值
38:1e:ea:77:fd:b5:59:45:b4:bf:39:2a:e9:23:09:ea:ce:ff:
32:ec:2d:32:77:22:b6:8c:54:7d:a4:e1:d6:b1:69:1a:3b:2c:
9b:d9:9d:fa:18:24:4c:12:fb:1b:b9:74:05:2e:8b:d7:bb:9b:
c9:bc:69:5d:eb:cf:2a:e0:8d:06:80:97:87:2d:48:2e:ca:0f:
19:df:5f:d0:ee:69:4b:5d:22:13:5c:56:9f:85:12:3c:12:5c:
bb:70:0b:55:f7:c7:3c:43:d3:91:a1:bf:54:1d:40:62:f0:e4:
64:87:1e:ea:92:ad:5e:b3:77:18:4d:46:68:f9:ee:20:ca:d4:
2e:04:4e:62:b4:fd:ed:df:48:ca:fc:8b:7e:ed:c0:1e:e2:46:
71:4e:42:56:5d:85:43:55:84:f3:eb:47:49:22:9f:29:65:9a:
29:6d:21:db:ec:34:f7:f7:56:37:fe:d9:15:ff:a7:67:a0:91:
f6:37:da:35:64:1d:95:9f:e1:e1:ff:60:b6:0b:33:d1:da:cc:
55:8c:1d:a6:ef:35:8d:a2:80:22:b8:b7:a6:ec:bd:fb:1a:b8:
36:47:3a:c1:e5:e9:0b:ff:e5:b7:b6:26:68:23:22:51:d5:7c:
ff:59:63:25
另外说明国密SSL指的传输层密码协议（TLCP）。只支持SM2的双证书，用户需要同时上传签名和加密两本证书，签名证书需要带有x509 v3扩展keyUsage digitalSignature或nonRepudiation，加密证书需要带有x509 v3扩展keyUsage keyAgreement或keyEncipherment或dataEncipherment。《GMT 0015-2012 基于SM2密码算法的数字证书格式》标准，规定了签名证书和加密证书的KeyUsage字段值。
证书的签名过程本质上涉及加密：
1.对整个证书进行哈希处理，然后使用私钥对哈希值进行加密。
2.验证者对整个证书进行哈希处理，获取哈希值，然后使用公钥对加密过的哈希值解密。如果解密值匹配，则确认私钥持有者执行了加密。签名的本质只是附加一个用私钥加密的哈希值到证书上。
简单来说，这意味着使用一个密钥加密的数据只能使用另一个密钥解密。一个密钥作为公钥发布，另一个密钥保持私有。
客户验证流程：
1）使用颁发者公钥验证签名：客户端会使用颁发者（通常是根CA或中间CA）的公钥来验证服务器证书上的数字签名。确保签名未被篡改：这一步确保证书未被修改或伪造。
2）找到信任根：客户端会查找并验证中间CA证书的有效性，直到到达一个已知的信任根CA证书。
3）验证中间CA证书：重复上述验证步骤，直到到达信任根。
4）信任根证书：信任根证书通常预装在客户端的操作系统或浏览器中，或者可以通过其他方式被显式导入。
网站需要确保两件事：
1.确保他们的证书不会过期。
2.保护他们的私钥不被泄露。如果其他人获得了私钥，证书就失去了“只有我才能证明我是谁”的意义。向 CA 请求证书时，仅提交公钥进行签名，因此只有网站应持有私钥。
一个潜在的问题是所有证书都有到期日期，包括 CA 根证书和中间 CA 证书。网站需要确保证书链中的每一个环节都没有过期。当前证书的有效期通常是12个月，每一年都需要做更新。未来证书可能会缩短证书的有效时间到90天。这样的好处是更短的时间更换私钥与证书更加安全，也会促使网站做自动证书更新。
根证书预埋：
一些业务会预埋CA证书，把证书提前放入到系统或应用指定位置。这样做的优势是可以确保只有经过严格审查的证书才能被系统或应用程序接受，从而增强通信的安全性。简化验证过程，预埋的根证书可以直接用于验证服务器证书，无需客户端每次连接时都从远程CA获取根证书，从而加快了验证过程，提高了连接效率。减少网络延迟，由于预埋的根证书可以直接用于验证，减少了与远程CA的交互，降低了网络延迟，提升了用户体验。
根证书预埋是存在风险的，例如证书更新问题：如果预埋的根证书或中间证书发生更新，而应用程序或系统未能及时更新预埋的证书，可能会导致通信失败或安全风险。
增加维护成本，预埋根证书需要定期更新和维护，以保持其有效性，这可能会增加系统的维护成本和复杂性。
7214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
