就 SSL 而言,证书和密钥之间有什么区别?

drs*_*drs 212 certificate ssl ssl-certificate

每当我试图了解有关 SSL 的任何内容时,我总是很难跟踪“密钥”和“证书”所指的内容。我担心很多人会错误地或互换地使用它们。密钥和证书之间有标准区别吗?

Law*_*ceC 194

证书包含一个公钥。

除了包含公钥之外,证书还包含其他信息,例如颁发者、证书的用途以及其他类型的元数据。

通常,证书本身由证书颁发机构 (CA) 使用 CA 的私钥进行签名。这将验证证书的真实性。

  • 您正在查看的乱码是 Base64 编码。这样做可能是出于类似的原因,将电子邮件附件转换为电子邮件附件 - 基本上是为了确保它们可以通过仅为 ASCII 设计的协议和机制进行传输,而无需随意修改,也无需担心换行符、括号等问题。`openssl`命令可以解码和解析这些,或者您可以使用在线实用程序,例如:http://lapo.it/asn1js/ (6认同)
  • @Zoredache如果证书通常只有一个公钥,是否有一个好名字来调用包含证书和私钥的 .p12 或 .pfx 文件? (4认同)
  • 这些附加信息埋在哪里?我正在看一些证书,这对我来说都是胡言乱语 (3认同)

And*_*ejs 135

这两张照片一起向我解释了一切:

来源:linuxvoice

在此处输入图片说明

资料来源:信息安全研究所

在此处输入图片说明

  • 第一个链接到 https://www.linuxvoice.com/masterclass-secure-your-website-with-ssl-encryption/,给出了证书错误。讽刺。 (6认同)
  • [相关xkcd](https://xkcd.com/1354/) (5认同)
  • 好的。1 说明:第一张图片是标准(单向)TLS 身份验证;第二,相互(2 路)身份验证。第一个中的 1 个额外标注将进一步帮助解释如何实际建立信任(所有这些都在 1 个看起来更友好的图片中):在客户端获得服务器的公钥证书后,客户端验证签署该证书的 CA服务器的证书包含在客户端的受信任 CA 的私有列表中(确定现在它也信任该 CA)。然后,可以安全地向服务器发送会话密钥,每个会话密钥现在都可以加密和解密后续通信。 (2认同)
  • 为什么服务器也使用CA来验证客户端的证书? (2认同)

Moh*_*ari 49

假设 A 公司有一个密钥对,需要发布他的公钥以供公众使用(在他的网站上也就是 ssl)。

  • 公司 A 必须向证书颁发机构 (CA) 发出证书请求 (CR) 以获取其密钥对的证书。
  • 公司 A 的密钥对的公钥,而不是私钥,作为证书请求的一部分包含在内。
  • CA 然后使用公司 A 的身份信息来确定请求是否满足 CA 颁发证书的标准。
    如果 CA 批准该请求,则向 A 公司颁发证书。简而言之,CA 用他(CA)的私钥对 A 公司的公钥进行签名,以验证其真实性。

因此,使用有效 CA 的私钥签名的公司 A 的公钥称为公司 A 的证书。

  • 办完以上手续后。A 公司将在其网站上拥有有效的 SSL 证书。任何访问该网站的访问者(浏览器)都将使用证书公钥来加密他的消息。拥有 SSL 证书私钥的公司 A 是唯一可以解密消息的公司。 (3认同)

Udd*_*tam 18

让我用一个例子来解释。

在普通的基于密钥对的 PKI 中,有私钥和公钥。

在基于证书的系统中,有私钥和证书。证书包含比公钥更多的信息。

Demo(可以生成证书和私钥):http : //www.selfsignedcertificate.com/

您可以下载打开私钥文件和证书文件,您会看到证书文件包含如下所示的很多信息。 在此处输入图片说明 在此处输入图片说明

您可以从以下站点匹配生成的证书(由文本编辑器打开)和私钥(由文本编辑器打开):https : //www.sslshopper.com/certificate-key-matcher.html

如果证书与客户端的私钥匹配,则客户端可以确定该证书是由客户端提供的还是由客户端的可信代理 (CA) 提供的。

但是,只有私钥和基于证书的通信存在问题

因为,任何人都可以生成自己的证书和私钥,因此除了服务器知道与证书公钥匹配的私钥之外,简单的握手并不能证明有关服务器的任何信息。解决此问题的一种方法是让客户端拥有一组它信任的一个或多个证书。如果证书不在集合中,则该服务器不可信

这种简单的方法有几个缺点。随着时间的推移,服务器应该能够升级到更强的密钥(“密钥轮换”),这将用新的公钥替换证书中的公钥。不幸的是,由于本质上是服务器配置更改,现在必须更新客户端应用程序。如果服务器不受应用程序开发人员的控制,例如,如果它是第三方 Web 服务,则这尤其成问题。如果应用程序必须与任意服务器(例如 Web 浏览器或电子邮件应用程序)通信,则此方法也存在问题。

为了解决这些缺点,服务器通常配置有来自称为证书颁发机构 (CA) 的知名颁发机构的证书。主机平台(客户端)通常包含它信任的众所周知的 CA 列表。与服务器类似,CA 具有证书和私钥。为服务器颁发证书时,CA 使用其私钥对服务器证书进行签名。然后,客户端可以验证服务器是否具有由平台已知的 CA 颁发的证书。

然而,在解决一些问题的同时,使用 CA 引入了另一个问题。因为 CA 为许多服务器颁发证书,所以您仍然需要某种方式来确保您正在与所需的服务器通信。为了解决这个问题,CA 颁发的证书使用特定名称(例如 gmail.com)或通配符集(例如 *.google.com)来标识服务器。

下面的例子将使这些概念更加具体一些。在下面的命令行片段中,openssl 工具的 s_client 命令查看维基百科的服务器证书信息。它指定端口 443,因为这是 HTTPS 的默认端口。该命令将 openssl s_client 的输出发送到 openssl x509,后者根据 X.509 标准格式化有关证书的信息。具体来说,该命令要求提供包含服务器名称信息的主题和标识 CA 的颁发者。

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Run Code Online (Sandbox Code Playgroud)

您可以看到该证书是由 RapidSSL CA 为与 *.wikipedia.org 匹配的服务器颁发的。

如您所见,由于 CA 向服务器发送了这些附加信息,客户端可以轻松知道它是否正在与其服务器进行通信。


She*_*har 5

SSL证书是从受信任的证书颁发机构获得的,该证书保证网站的安全连接。SSL 证书通常包含身份验证徽标以及加密和解密要发送到计算机的数据所需的公钥。SSL 密钥功能

在会话期间可以生成多个 SSL密钥。它们用于加密和解密发送到计算机和从计算机发送的信息。密钥用于验证信息未被修改或篡改。

生命周期差异

证书的持续时间比 SSL 密钥更长。SSL 证书是从证书颁发机构获得的,银行和企业可以定期更新。另一方面,SSL 密钥或会话密钥是在会话期间唯一生成的,并在会话结束时被丢弃。

在这里阅读更多内容