客户端如何从自签名证书中提取公钥？

Question

我已经过去了：

• 我们为什么要签自签的证书？
• 基本的自签名证书问题
• 自我签名的SSL证书比没有好得多吗？

我是密码学和安全方面的新手。我正在努力理解自我签署证书的意义。

我理解证书作为一种分发公钥的方法，其中可信CA (颁发者)“签名”(=>encrypts)主体的公钥和信任此CA的客户端使用颁发者的公钥(CA)解密(未签名)证书并获取主题(服务器)的公钥。我从Behrouz.A.Forouzan 4th.edition Page987的数据通信和网络中了解了这一点。

现在，如果我的理解是正确的，我如何将这个逻辑扩展到一个自签名的证书！如果主体与发行人匹配，而客户的总体目的是获取主体(服务器)的公钥，客户端如何使用发行人的公钥解密(未签名/打开)证书以获取主体的公钥，因为发行人的公钥是主体的公钥？客户端如何获得它最终想要建立SSL会话的主题(服务器)的公钥？

这个问题在任何地方都没有被问到，这告诉我，一定有一些我还没有理解的基本问题。请帮助我理解这一点。

Answer 1

这里有几个重大误解。

首先，那本书是错的。签名不是加密的形式，也不是验证解密的形式。在RSA的具体情况下，签名在数学上等同于“用私钥加密”，但这更多地是一种巧合，而不是数字签名的固有属性。有些数字签名算法根本不支持实际加密！(DSA和ECDSA是最明显的。)从概念上讲，这两个操作(签名和加密)的使用非常不同，实际上实现者需要考虑许多问题(填充、长度等)。这适用于一个操作，但不适用于另一个操作，即使是RSA。

第二，签名从来不会以隐藏原始消息的方式完成。这可能是本书误导你的另一种方式:从概念上讲，所有签名操作都需要两个输入(一个消息和一个私钥)，并产生一个输出(没有原始消息就没有意义的短字符串/大数字)。输入--包括消息--不被修改。通常，签名的实际操作只能在一小块数据上完成，因此消息首先进行加密散列(当您说“signing”时，密码工具包通常会自动完成这一操作)，但是有些算法会对整个消息进行工作，并且在内部执行类似哈希的操作，同时也生成签名。从用户的角度来看，这仍然是“符号M与K"，只是一个密钥K使用了不同的数字签名算法。

无论如何，签名操作的实际输出是，除了私钥和公钥对之外，现在还有两条数据--消息M及其签名S。任何拥有M，S，和公钥的人都可以验证S是从M中使用相应的私钥创建的，如果M和1996都没有被修改，那么当然你必须分发M，并且没有变化。请注意，S通常比M小得多，从概念上不可能从S中提取M。

现在，在实践中，签名通常是(并不总是！)和加密一起使用。加密时，你确实修改了M --或者至少，你生成了C，M的密文，并且保持M的秘密--然后接收者必须解密C(以获得M)，然后他们才能验证签名S，或者你签署加密的消息C而不是签署纯文本M，因此您的S被验证为C而不是针对M，因此这一段中的任何内容都与证书无关，因为证书没有任何加密！

有了这些澄清，希望你能理解为什么这个问题是微不足道的。证书由四个部分组成(可以说是)：关于证书的数据(签发时、由谁签发、多长时间、用于什么目的)、关于证书主体(向谁颁发证书)、主体的公钥以及签发人签署前三部分的数据。前三个部分是纯文本，而最后一个部分--签名--没有纯文本就没有意义。

因此，通过解析证书结构并读取证书的相关部分(包含公钥的部分)，可以从自签名证书(或从任何证书的任何其他部分)提取公钥。就这样。签名行为不会也绝不能修改证书的任何部分(存储签名的部分除外)。