SSL 证书旨在证明什么,它是如何做到的?

信息安全 tls 证书 隐私 公钥基础设施
2021-08-10 19:29:57

如果我从知名提供商处获得 SSL 证书,这能证明我的网站是什么以及如何证明?

这是我所知道的:

  • 假设 Alice 和 Bob 都有公钥和私钥
  • 如果 Alice 用 Bob 的公钥加密了一些东西,她确保只有 Bob 可以解密它(使用他的私钥)
  • 如果 Alice 用她自己的私钥加密某些东西,任何人都可以解密它(使用她的公钥),但他们会知道它是由她加密的
  • 因此,如果 Alice 先用自己的私钥加密消息,然后用 Bob 的公钥加密,她将确保只有 Bob 可以解密它,并且 Bob 会知道该消息来自她。

关于证书,这是我认为会发生的事情(更新):

  • 我生成证书请求。在那个请求中,我输入了我的公钥和一堆关于我自己的信息。
  • 证书颁发者(理论上)会检查我以确保它知道我是谁:亲自与我交谈,查看我的驾驶执照,视网膜扫描或其他任何东西。
  • 如果他们满意,证书颁发者就会用他们的私钥加密我的请求。任何用他们的公钥解密它的人都知道他们保证它包含的信息:他们同意公钥是我的,并且所陈述的关于我的信息是真实的。这个加密的背书是他们发给我的证书。
  • 当您通过 https 连接到我的网站时,我会向您发送证书。
  • 您的浏览器已经知道颁发者的公钥,因为您的浏览器已经安装了该信息。
  • 您的浏览器使用发行者的公钥来解密我发送给您的内容。颁发者的公钥用于解密它的事实证明了颁发者的私钥被用来加密它,因此,颁发者确实创建了这个证书。
  • 解密信息里面是我的公钥,你现在知道它已经被担保了。你用它来加密一些数据发送给我。

是对的吗?如果没有,有人可以非常清楚地列出这些步骤吗?

3个回答

您的密钥理论:基本上是正确的,但身份验证通常是通过加密数据的加密安全哈希而不是数据本身来完成的。

SSL 证书上的 CA 签名应表明 CA 已尽了一定的努力以确保证书上的凭据与所有者匹配。尽职调查各不相同,但最终的一点是他们说他们签署的证书属于上面命名的实体。

http://en.wikipedia.org/wiki/Digital_signature#Definition

公钥证书是公钥、标识符和可能的其他属性之间的签名组合。签署本文件的人有效地断言了公钥和标识符以及这些属性之间绑定的真实性,就像护照签发机构断言照片和护照中的姓名之间的绑定一样,其他各种信息(国籍,出生日期,...)。

首先,对术语进行一些澄清:

  • 严格来说,不存在“SSL 证书”之类的东西。大多数情况下,这是“用于 SSL/TLS 的 X.509 证书”的简短表达。(SSL/TLS 也能够使用其他类型的证书,例如OpenPGP 证书,尽管这种情况不太常见。)

  • 您在这里对“加密”和“解密”的使用不正确。在公钥密码学中:

    • 私钥用于签名解密/解密
    • 公钥用于验证签名加密/加密

    请参阅TLS 规范的词汇表

    公钥密码术:一类使用双密钥密码的密码技术。用公钥加密的消息只能用相关的私钥解密。相反,用私钥签名的消息可以用公钥来验证。

    术语上的这种区别似乎并不重要,因为就 RSA 而言,这些操作大致相同(实际上您会发现RSA_private_encryptOpenSSL 中调用的底层例程),但是 (a) 这不适用于 DSA 和(b) 不理解这一根本区别可能会导致您在整体安全方案方面犯错误。

    特别是,加密的目的是隐藏某些东西。当您在这里谈论“使用私钥加密”时,它没有任何意义,因为任何人都知道公钥。此外,不需要发行人的公钥来查看该发行人已签署的证书,因为任何人都可以看到所有内容(请参阅TBSCertificate结构)。这里没有隐藏任何东西。

    (使用 RSA 进行签名的操作实际上与加密操作或多或少相同,但使用私钥应用于要签名的消息的加密摘要,如今通常使用 SHA-1 进行证书。)

您的服务器证书打算证明的是 CA 以某种方式验证了您的主机名和证书请求之间的绑定(更具体地说,是证书请求中的公钥)。至少,它会向域名所有者发送电子邮件(对于域验证证书)。(请参阅此处的验证模式之间的区别。)

颁发的证书的内容应符合 RFC 3280/RFC 5280,它们定义了客户端应如何验证和验证证书。这将定义可以使用哪些属性,特别是通常(扩展的)密钥使用属性,例如“TLS 服务器”。

结果,您的 X.509 服务器证书将绑定在一起:

  • 公钥(您拥有私钥)。
  • 颁发者名称(CA 证书主题 DN)。
  • 服务器名称(根据 RFC 2818 第 3.1 节或 RFC 6125),在主题备用名称扩展或主题可分辨名称的通用名称中。
  • 使用扩展。
  • 可能还有其他扩展(关键或非关键),例如 EV 证书策略。

这一切都放在X.509 证书的TBSCertificate结构中。然后,使用加密散列算法(例如 SHA-1)对该结构进行消化,并使用 CA 的私钥对其进行签名以形成签名(signatureValue在结果中Certificate)。

当使用证书时,客户端可以验证这个签名(使用它知道的 CA 的公钥,或者通过使用多个 CA 证书构建一个到它知道的信任锚之一的证书路径),检查使用属性是否与 SSL 兼容/TLS 用法并检查它请求的主机名是否与为其发出的主机名匹配。

应该指出,与所有其他答案一起,您的私钥并不总是只是用于解密和签署消息的一个密钥。这些应该是两个单独的键。这将为每个人创建 4 个密钥:

公共加密密钥- 用于加密要发送给我的数据。

私有解密密钥- 用于解密使用我的公共加密密钥加密的消息。

私人签名密钥- 用于签署我发送给其他人的消息。

公共验证密钥- 用于验证消息实际上是否由我签名。

有一些理由为此使用单独的键。有关更多详细信息,请参阅此讨论