我问这个问题是为了100%肯定。
验证证书以确保其包含信息 由证书颁发机构,Web浏览器进行数字签名 验证数字签名。因为数字签名是一个 基于内容计算的加密哈希值 证书,Web浏览器需要比较哈希值。网络 浏览器根据证书的内容计算哈希值 它收到了。然后它解密数字签名以确定 证书颁发机构计算的哈希值。如果两个哈希 值匹配,Web浏览器确保证书包含 证书颁发机构验证和数字化的信息 签名。
问题:
Web浏览器根据内容计算哈希值 它收到的证书
浏览器知道在其中使用证书的摘要算法,因此他使用也来计算哈希值 - 基于证书内容。
然后解密数字签名以确定哈希值 证书颁发机构计算
浏览器知道哪个CA创建了证书,因此他从相应的计算机存储位置获取公钥,并将其应用于加密的哈希值。结果是解密的哈希值。
然后看两者是否相同。
我是对的吗?
答案 0 :(得分:4)
(您可能对Security.SE上的this question感兴趣。)
这是structure of an X.509 certificate:
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中)。使用私钥“加密”是没有意义的,因为“加密”意味着隐藏(如果您将公钥放弃,那么您就不会隐藏任何内容,因此它可以“解密”签名)。 / p>
这种关于数字签名的散列和加密的巧妙处理不适用于DSA等其他算法,仅适用于签名。
这就是为什么许多数字签名API将散列和密钥用法组合成单个“签名”或“验证”操作的原因。这就是Java Signature API所做的事情,例如:您告诉它使用RSAwithSHA1
或DSAwithSHA1
,给它键和消息,并告诉它签名或验证,你不必手动进行摘要或“加密”。
出于证书验证的目的:浏览器从证书中获取颁发者并找到相应的公钥(来自可信CA证书),它还从证书中获取签名算法,然后使用该公钥验证签名和TBSCertificate内容,根据签名算法的规定。