Roy*_*mir 0 security ssl certificate public-key-encryption
我问这个问题是为了 100% 确定。
为了验证证书以确保它包含由证书颁发机构数字签名的信息,Web 浏览器会验证数字签名。由于数字签名是根据证书内容计算的加密哈希值,因此 Web 浏览器需要比较哈希值。Web 浏览器根据它收到的证书的内容计算哈希值。然后解密数字签名以确定证书颁发机构计算的哈希值。如果两个哈希值匹配,则 Web 浏览器确信该证书包含证书颁发机构验证和数字签名的信息。
问题 :
Web 浏览器根据收到的证书内容计算哈希值
浏览器知道证书在哪个摘要算法中使用,因此他也使用它来计算哈希 - 基于证书内容。
然后解密数字签名以确定证书颁发机构计算的哈希值
浏览器知道哪个 CA 创建了证书,因此他从适当的计算机存储位置获取公钥并将其应用于加密的哈希值。结果是解密的哈希值。
然后看看两者是否相同。
我对吗 ?
(您可能对 Security.SE 上的这个问题感兴趣。)
Run Code Online (Sandbox Code Playgroud)Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 }
当提供证书时,浏览器从证书本身获取签名算法。通常,这类似于RSAwithSHA1.
在这种情况下,它确实可以重新计算TBSCertificate(证书的实际内容)的 SHA-1 摘要。
此外,TBSCertificate它可以从中找到颁发者名称:这是用于从已知 CA 证书中查找信任锚的内容(颁发者名称必须与 CA 证书的主题匹配)。当它在已经信任的列表中找到具有正确名称的 CA 证书时,它可以从该 CA 证书中获取公共 RSA 密钥。
拥有 SHA-1 摘要和 RSA 公钥,它可以验证signatureValue匹配。
数字签名是一个加密的哈希值
严格来说,这并不完全正确,尽管人们普遍这么说。数字签名是数字签名,而不是加密。
问题是 RSA 使用相同的数学来加密和签名:用公钥加密,用私钥签名。通常,一个与另一个混淆(即使在 OpenSSL API 中)。用私钥“加密”是没有意义的,因为“加密”意味着隐藏(如果您将公钥提供出去,那么您就不会隐藏任何东西,以便它可以“解密”签名)。
这种巧妙地使用数字签名的散列和加密不适用于其他一些算法,例如 DSA,这些算法仅用于签名。
这就是为什么许多数字签名 API 将散列和密钥用法组合成单个“签名”或“验证”操作的原因。这就是 Java签名API 所做的,例如:您告诉它使用RSAwithSHA1or DSAwithSHA1,给它密钥和消息,并告诉它签名或验证,您不必手动进行摘要或“加密”。
用于证书验证:浏览器从证书中获取颁发者并找到相应的公钥(来自受信任的CA证书),它也从证书中获取签名算法,然后使用该公钥和TBSCertificate验证签名内容,根据签名算法的规定。
| 归档时间: |
|
| 查看次数: |
9240 次 |
| 最近记录: |