Https 了解证书在客户机-服务器交互中的工作方式

所以，我试图了解证书是如何真正、真正地工作的——我一直无法在谷歌上找到我想要的东西，所以我用自己的方式来表达。。。如果有一个直接的链接，你认为可能会帮助我-请张贴它，我会删除这个问题

我知道，当客户端（比如浏览器）向网站发出请求时，它会通过检查其证书来验证网站的身份。不鼓励使用自签名证书，来自证书颁发机构（及其分支机构）的证书才是真正的交易。现在身份已经被验证，请求由服务器处理，响应被发送到客户端，现在用户（一个人）可以在他们的浏览器上看到URL旁边的绿色锁标志。我总结得对吗？这个响应是加密的，并且将由浏览器/客户端解密

对于SSO（单点登录）流，当SAML断言是“数字签名”时，这到底意味着什么？上述证书在这方面有何帮助

---

我脑子里有太多的概念，想弄清楚系统、安全性和TLS。

首先，这都是关于非对称加密的。这允许使用一个密钥加密消息，并使用另一个密钥解密。为什么这有帮助

安全交互

您可以使用服务器的公钥向服务器发送消息。因此，您可以确保没有其他人（除了该服务器）能够解密该消息

数字签名

您可以使用私钥加密消息摘要，任何人都可以通过使用公钥解密您的“签名”来检查这是否是您

证书涉及的阶段是什么

上述两种情况都有一个陷阱。您无法确定服务器提供给您的公钥是否确实是您信任的一方的密钥。签名也一样。您无法确定刚刚成功用于验证签名的公钥是否真的是您希望签署合同的人的密钥

证书是公钥和密钥对持有者信息的捆绑包。此捆绑包使用CA的私钥进行数字签名

什么是端到端流程

让我们考虑HTTPS案例。您的客户端对服务器说“嘿，我想使用https协议”。这就是涉及非对称加密的地方。您可以使用服务器的公钥来加密对称密钥（因为非对称加密有点昂贵，仅在协商对称密钥时使用），该密钥将用于加密流量

但是，您如何确保能够信任该服务器呢。实际上，服务器发送给您的不仅仅是一个密钥，而是一个证书。您获取证书并验证证书中指定的服务器名称实际上是您在地址栏中使用的名称。您还可以使用CA的公钥验证CA的签名

认证链

签署服务器证书的CA的公钥也可能需要验证。以与上述相同的方式执行此类验证。链最终必须在您绝对信任的证书处停止。此类证书存储在所谓的信任存储库中

---

这就是ssl的工作原理。数字签名SAML断言的工作方式非常相似。它们提供证书，您可以验证并使用从中提取的公钥来验证断言的签名。

您即将使用HTTPS（web）和其他SSL/TLS的证书，除了没有一个证书颁发机构，而是几个独立的证书颁发机构——但浏览器或操作系统信任库通常有~100个。SSL/TLS的规范答案是关于这个主题的更多内容。对于web，一旦建立并保护HTTPS（或WebRTC）连接，可能会有多个请求和响应。。。。。。SSO和SAML是完全不同的东西，与SSL/TLS无关，尽管它们可能对证书使用相同的技术标准。如果您有更具体的问题，security.SX可能也适用于这些问题。对于每个后续请求和响应，是否每次都验证证书？这取决于依赖方，通常只有client=browser，尽管我怀疑大多数仅在握手时进行检查。然而，连接通常只在很短的时间内保持空闲——可能只有几分钟。这仍然可以允许每次连接数十个或数百个请求，特别是在现代web设计中，在这段时间内，有效性不是什么大问题。我明白了！所以，当我生成一个SAML断言并对其进行签名时，会发生什么？我使用私钥对其进行签名，对吗？在断言中我包含了公钥信息？因此，当服务提供者收到该公钥信息和摘要时，它将使用该公钥信息进行解密并断言其有效性。我理解对了吗？我想我的痛点是理解当私钥只有一方知道时，加密/解密是如何工作的，而另一方是如何“弄明白”并解密的：）如果我们谈论的是签名，你可以将私钥看作是用于加密的密码（你将其存储在安全的地方）以及公钥作为用于解密的密码（每个人都可以拥有它）。因此，在SAML中，您使用私钥对断言进行签名，并提供包含公钥的证书（因为它不是秘密的）。客户机验证证书（在其信任存储中查找证书，或者验证签署证书的CA在客户机的信任存储中有证书），如果可以，则接受该密钥（又名公共密码）