如果 SSL/TLS 证书没有真正的签名/CA，为什么它们是自签名的？
据我所知，通常 SSL（或更准确地说 X.509）证书应该由某个认证机构签名，以确保它是真实的。
在某些情况下，不存在这样的签名，例如，如果您出于测试目的生成证书，或者您是证书颁发机构（根证书）。 在这些情况下，使用自签名证书。
我的问题：为什么要使用这种奇怪的自签名结构？ 为什么证书不能简单地没有任何签名？ 包含自签名签名有什么好处？
或者只是因为在每个证书中始终有一个签名在技术上更容易（没有签名的特殊情况），即使它是一个毫无意义的签名？
I understand that normally an SSL (or more precisely X.509) certificate is supposed to be signed by some certifying authority to assure that it is genuine.
In some cases no such signature exists, e.g. if you generate a cert for testing purposes, or if you are the certifying authority (root certificate). In these cases, self-signed certificates are used.
My question: Why use this weird construct of self-signing? Why can a certificate not simply not have any signature? What does including a self-signed signature gain?
Or is it just because it's technically easier (no special case for no signature) to always have a signature in every certificate, even if it's a meaningless signature?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
证书具有三个主要部分
证书的签名方法是使用私钥对前两部分进行加密，然后将该加密信息附加到证书的末尾。 如果您可以使用证书中包含的公钥解密签名，那么您就知道该证书是由持有匹配私钥的人签署的。 签名将身份信息与公钥绑定。 我用我的私钥签署我的证书，以便您知道只有我可以读取您可能用我的公钥加密的消息。
现在，除非你真的见过我本人并且我把我的证书交给你，否则你无法真正知道身份信息是我的。 证书的最初目的是建立一个信任网络，首先获取你见过的人的证书，然后信任那些拥有这些人签名的证书的人，然后那些人......
A certificate has three main parts
A certificate is signed by encrypting the first two parts with a private key, then appending that encrypted information to the end of the certificate. If you can decrypt the signature with the public key contained in the certificate, then you know that certificate was signed by the person that holds the matching private key. The signature binds the identity information to the public key. I sign my certificate with my private key so that you know only I can read messages that you might encrypt with my public key.
Now, unless you've really met me in person and I hand you my certificate, you can't really know that the identity information is legitimately mine. The original purpose of certificates was to establish a web of trust by first obtaining the certificates of people that you have met in person, then trusting people that have certificates signed by those people, then those people...
想象一下，您正在建立自己的证书颁发机构，第一个证书颁发机构：谁签署您的证书？
理解整个认证过程的方法是将其视为一系列含义：您收到了一份证书。 你应该相信它吗？ 您可以信任颁发者，或者查看证书并同意您信任签名者。 如果您不认识签名者，可以根据该签名找到该签名者的签名者，依此类推。 不过，最终您将获得自签名证书。
不过，获得证书相对昂贵并且可能很复杂，因此有些人直接创建自己的签名权限。 由您决定他们是否值得信任。
关于此的一些评论变得有点愚蠢。 您无法制作没有签名的证书，因为要成为有效的证书，证书必须具有签名。 这就是它们的定义方式。 您不妨问为什么不能有没有指数的浮点数。 证书的存在是为了收集一些身份信息以及用于识别颁发者以确定信任的加密机制。 如果没有签名，证书的“证书性”所必需的一些东西就会丢失。
好吧，让我们问一些其他问题：
让我们再试一次。 什么是证书？ 它是一种将名称绑定到非对称加密密钥的公共端的数据结构。 该结构是“签名的”，这意味着您可以检测它是否被签名密钥所有者以外的任何人更改。 由于您可以验证该签名，因此您对证书的真实性有一定程度的信任。 因此，有效的证书必须具有可验证的签名。
在这种情况下，“信任”意味着您愿意冒着无法根据他人的授权完成您负责的事情的风险。 如果您拥有由 Verisign 等知名 CA 签署的证书，则您信任的权威实体就是 Verisign； 您使用以某种值得信赖的方式从他们那里获得的证书来验证他们是否签署了您正在考虑的证书。
当您拥有自签名证书，而不是由知名机构签署的证书时，您就表示如果您接受该证书，您愿意信任自签名者。 您愿意接受的唯一权威是您对自我签名者的直接信任。 但您至少确信证书未损坏，因为您可以验证签名。
因此，现在考虑一个没有任何签名的证书。 （从技术上讲，这称为“数据项”。）我可能包含名称和公钥之间的关联，但如果没有签名，您就无法确信它没有被第三方修改过派对。
看到区别了吗？ 有了签名的证书，您就拥有了一个双方认可的可信第三方。 使用自签名证书，没有第三方，但您可以确信证书没有被第三方损坏。 它可以像您信任证书的颁发者一样受到信任：您可以验证它是否是由拥有相应密钥另一方的人颁发的。
对于未签名的“证书”，您既无法保证受信任的第三方将证书颁发给正确的人，也无法保证“证书”一旦颁发就不会被恶意者修改。第三者。 这就是为什么根据定义证书必须有签名。
Imagine that you're setting up your own certification authority, the very first one: who signs your cert?
The way to understand the whole certification process is to think of it as a chain of implications: You have a cert presented to you. Should you trust it? Either you can trust the issuer, or you look at the certificate, and agree that you trust the signer. If you don't know the signer, you can follow it back to THAT signer's signer, and so on. Eventually, though, you'll get to a self-signed certificate.
Getting a cert is relatively expensive and can be complicated, though, so some people make their own signing authority directly. It's left to you to decide if they can be trusted.
Some of the comments about this have gotten a little silly. You can't make a cert without a signature because a cert, to be a valid cert, must have a signature. That's the way they're defined. You might as well ask why you can't have a floating point number without an exponent. Certs exist so that there is some collection of identity information and a cryptographic mechanism for identifying the issuer in order to determine trust. Without the signature, something essential to the "cert-ness" of the certificate is lost.
Okay, let's ask some other questions:
Let's try once more. What is a cert? Its a data structure that binds a name to the public side of an asymmetric encryption key. That structure is "signed", which means you can detect if it was changed by anyone other than the owner of the signing key. Because you can verify that signature, you have a degree of trust in the certificate's authenticity. Thus a valid cert must have a verifiable signature.
"Trust" in this context means that you are willing to risk failing to perform something you're responsible for, on someone else's authority. If you have a cert that is signed by a well-known CA like Verisign, the entity whose authority you're placing your trust is Verisign; you use a cert you obtained from them in some trustworthy manner to verify that they signed the certificate you're considering.
When you have a self-signed cert, instead of one signed by a well-known authority, then you're saying you're willing to trust the self-signer if you accept the cert. The only authority on which you can base your willingness to accept is the direct trust you put in the self-signer. But you at least have confidence that the cert is uncorrupted because you can verify the signature.
So, now consider a cert with no signature whatsoever. (Technically, this is called "a data item.") Iy may contain an association between a name and a public-side key, but without a signature, you can have no confidence it hasn't been modified by a third party.
See the difference? With a signed cert, you have an agreed-upon trusted third party that both whose authority both sides accept. With a self-signed cert, there is no third party but you can be confident the cert hasn't been corrupted by a third party. It can be trusted as much as you trust the issuer of the cert: you can verify that it was issued by someone who had the other side of the appropriate key.
With an unsigned "cert", you neither have the assurance from a trusted third party that the cert was issued to the right person, nor do you have any assurance that the "cert", once issued, hasn't been modified by a malicious third party. This is why, by definition a cert must have a signature.
如果您对证书进行自签名，则可以向某人证明您实际上控制该签名的密钥 - 即，它是您的证书。
否则，您可以创建一个随机数且符合证书格式的公钥，但不是真正的证书。
If you self-sign the certificate, it proves to someone that you actually control the secret key to that signature - ie, it is your certificate.
Otherwise, you could just create a public key that is random numbers and conforms to the format of a certificate, but isn't a real certificate.
自签名/根证书不提供有关证书作者的证据。 自签名证书必须以某种方法建立信任，而不是检查证书颁发机构创建的签名，因为这些证书是最终颁发机构。 因此，自签名证书必须通过替代机制提供，例如将它们与操作系统或网络浏览器或其他（希望安全的）侧通道捆绑在一起。
任何人都可以使用自己拥有的密钥对创建具有有效签名的自签名证书。 那么自签名证书上的签名保护的是什么？ 证书元数据。
对于 X.509 证书，一些元数据是：序列号、颁发者名称、有效期、主题名称等。
自签名证书上的签名证书证明证书创建者在创建时实际上拥有证书的私钥，并用它来签署证书中包含的特定元数据。 修改证书的任何部分都会使其失效。 鉴于签名可以防止证书本身被修改，验证自签名证书签名可以提供什么安全性？ 我认为：没什么真正的。
攻击者以任何方式影响您计算机上的根证书的能力将构成严重的安全漏洞，因为这将允许攻击者添加新的自签名/根证书并为现有网站颁发伪造证书，或为以下网站创建证书通常不应信任的网站。 因此，有必要确保受信任的自签名证书的安全传递，因此通过验证自签名证书上的签名不会获得额外的安全性。
请允许我提供明确的证据，证明自签名证书上的签名并不重要：OpenSSL 文档。
默认情况下，当您使用 OpenSSL 时，它不会验证自签名/根证书的签名！ 如果运行命令
man openssl-verification-options，您将发现以下内容：关键引用：“它不会添加任何安全性”。
但也许还有一些非安全功能！ 您可以出于 OpenSSL 手册页中描述的原因忽略验证 X.509 位，并根据证书中的公钥验证签名。 如果使用该技术签名有效，您可以使用它作为识别自签名证书的方法。 唉，已经有另一种推荐的方法来识别自签名证书，请参阅 https://security.stackexchange.com/questions/93162/how-to-know-if-certificate-is-self-signed
所以最后一个问题：为什么自签名证书有签名，如果它没有添加任何安全或有用的功能？ 我的猜想：自签名证书经过签名，使其具有与其他 X.509 证书相同的格式（元数据 + 公钥 + 签名）。 无论如何，这是我的猜测。
另一个参考： https://security.stackexchange.com/questions/150882/security-benefit- Purpose-of-signature-on-self-signed-certificate-in-trusted-st
接受答案中的相同结论:
A self-signed/root certificate offers no evidence as to the author of the certificate. Self-signed certificates must establish trust in some method other than checking the signature created by a certificate authority since these certificates are the final authority. Thus self-signed certificates must be delivered via an alternate mechanism such as bundling them with an operating system or web browser, or other--hopefully secure--side channel.
Anyone can create a self-signed certificate with a valid signature using a key pair they own. So what is being protected by the signature on a self-signed certificate? The certificate metadata.
For X.509 certificates some of the metadata is: serial number, issuer name, validity period, subject name, etc.
The signature on a self-signed certificate proves the certificate creator actually had the private key for the certificate at the time of creation and used it to sign the specific metadata included in the certificate. Modifying the any part of the certificate would invalidate it. Given that the signature protects against the modification of the certificate itself, what security would validating the self-signed certificate signature provide? I argue: nothing really.
The ability of an attacker to influence the root certificates on your machine in any way would constitute a serious security vulnerability since that would allow an attacker to add a new self-signed/root certificate and issue forgery certificates for existing websites, or create certificates for websites that shouldn't normally be trusted. Thus it is already necessary to ensure the secure delivery of trusted self-signed certificates and thus there is no extra security to be gained by verifying the signature on a self-signed certificate.
Allow me to present definitive evidence that the signature on a self-signed certificate doesn't matter: the OpenSSL documentation.
By default when you use OpenSSL it doesn't verify a self-signed/root certificate's signature! If you run the command
man openssl-verification-optionsyou will find the following:Key quote: "it doesn't add any security".
But maybe there is some non-security functionality to be had! Well you could ignore validating the X.509 bits for reasons described in the OpenSSL man page and verify the signature against the public key in the certificate. If the signature is valid using that technique you could use that as a way to identify self-signed certificates. Alas there is already another recommended way to identify self-signed certificates, see https://security.stackexchange.com/questions/93162/how-to-know-if-certificate-is-self-signed
So the final question: why do self-signed certificates have a signature if it doesn't add any security or useful functionality? My conjecture: Self-signed certificates are signed so that they have the same format as other X.509 certificates (metadata + public key + signature). Anyway that's my guess.
Another reference: https://security.stackexchange.com/questions/150882/security-benefit-purpose-of-signature-on-self-signed-certificate-in-trusted-st
Same conclusion in accepted answer:
我想这是为了确保你不能用证书“撒谎”——也就是说，除非私钥持有者同意，否则你不能创建证书。 这可以通过 CA 验证证书指定的实体是私钥持有者来确保，或者在自签名的情况下，通过让密钥持有者自己签署证书来确保。
I imagine it's to ensure that you can't "lie" with certificates - ie, you can't create a certificate unless the private key holder agrees to it. This is ensured either by the CA verifying that the entity named by the certificate is the private key holder, or in the self-signed case, by having the key holder sign the certificate itself.
您需要了解 RSA 加密的工作原理。 签名者生成两个加密密钥，一个私有密钥，一个公共密钥。 他们为您提供公钥，并使用私钥加密数据。 有了公钥，您就可以验证数据是否由正确的人加密，因为没有其他人拥有其私钥。 对于签名证书来说，存在一个信任网络，您可以在其中验证相对较少的个人（证书颁发机构）的身份，并且您在第三方验证方面信任他们。 根据系统工作方式的本质，每个证书都必须进行签名。 证书可以由任何人签名，当您不关心签名者的可验证性时，“自签名”证书是最简单的方法。
You need to understand how RSA encryption works. The signer generates two encryption keys, one private and one public. They give you the public key, and encrypt data with the private key. Having the public key, you are able to verify that the data was encrypted by the correct person, because no one else has their private key. In the case of a signed certificate, there is a web of trust, in which you can verify the identity of relatively few individuals (the certificate authorities), and you trust them with regard to the verification of third parties. Every certificate must be signed, by the very nature of how the system works. A certificate can be signed by anyone, and "self-signed" certificates are the simplest approach when you don't care about the verifiability of the signer.
证书包含服务器的公钥。 自签名证明生成证书的人也拥有私钥。
Certificate contains the server's public key. Self-signature is a proof that whoever generated the certificate also posseses the private key.
证书为您提供有关已签名密钥的实体的信息，但它们不会为您提供有关正在签署密钥的实体的信息。 因此，自签名证书至少有一个目的：它们告诉您根密钥的所有者是谁，而无需实现特殊的数据结构。
在我看来，这些东西不应该被称为证书，因为它们具有不同的属性。 普通证书不需要安全存储/传输。 如果攻击者设法用假证书替换合法证书，那么证书验证就会失败。 对于自签名证书来说情况并非如此。 如果攻击者有机会替换自签名证书，他/她可以用用他/她的私钥签名的证书替换该证书，并且通过验证证书无法检测到伪造。
另请注意，自签名证书的逻辑有些倒退。 您要做的第一件事就是相信某个公钥是真实的。 如果这样做，您可以了解公钥属于谁。 通常人们会想要相反的情况。 您决定某个实体可以信任。 然后您尝试了解属于该实体的公钥。
在我看来，自签名证书应该被放弃。 例如，我希望 Internet Explorer 中的所有根密钥都由 Microsoft 签名。 毕竟，是 Microsoft 验证了证书属于合法 CA，并且是 Microsoft 决定普通用户应该能够信任这些 CA。 现在，如果我担心有人篡改了我的证书，我所要做的就是检查 Microsoft 的密钥是否仍然是他们的，然后验证每个证书上的签名。
Certificates give you information about the entity of the key that is signed, but they don't give you infromation about the entity that is signing the key. So self-signed cerfificates serve at least one purpose: They tell you who the the owners of the root keys are, without having to implement special data structures.
In my opinion these things shouldn't be called certificates, because they have different properties. Ordinary certificates don't need to be stored/transmitted securely. If an attacker manages to substitute a legit certificate with a fake one then the certificate verification should fail. The same isn't true for self-signed certs. If an attacker has the opportunity to substitute a self-signed certificate he/she can substiture that certificate with one that is signed with his/her private key and the forgery cannot be detected by verifying the cert.
Also notice, that logic of self-signed certs is somewhat backwards. The first thing you have to do is trust that some public key is authentic. If you do so you can learn to whom the public key belongs. Usually one would want the reverse. You decide that an entity can be trusted. Then you try to learn the public key that belongs to that entity.
In my opinion, self-signed certificates should be abandoned. E.g., I'd prefer to have all root keys in the Internet Explorer signed by Microsoft. After all it is Microsoft who validated that the certs belong to legitimate CAs and it is Microsoft who decides that the average user should be able to trust these CAs. Now if I'm worried that someone tampered with my certs, all I have to do is check that Microsoft's key is still theirs and then verify the signatures on every cert.
证书的目的是验证身份。 证书的签署者向证书的所有接收者断言他们已经验证了身份信息的真实性及其与证书中包含的公钥的关联。 如果证书未签名，则无法验证身份，因此没有理由使用证书。 在这种情况下，您可以使用不需要身份验证的密码，因此不严格要求身份信息。 我认为RC4符合这个描述。
您的问题意味着您不需要自签名证书，因为您知道您信任自己。 因此，您可以在服务器和客户端之间预先共享证书。 从假设的密码学角度来看，这是可行的； 您的身份验证信息将受到保护。 然而，非对称密钥加密工具和证书格式都不支持这种用途，因为与具有预共享秘密的对称密钥密码相比，它没有提供任何好处。
The purpose of a certificate is to verify identity. The signer of the certificate is asserting to all recipients of the certificate that they have verified the authenticity of the identity information and it's association with the public key contained in the certificate. If the certificate is not signed then there is no verification of identity and thus no reason to use a certificate. In such a scenario you could use a cipher that does not require authentication and thus does not strictly require identity information. I think RC4 fits this description.
Your question implies that you wouldn't need to self-sign a certificate since you know that you trust yourself. Thus you could pre-share the certificate between the server and client. From a hypothetical cryptographic standpoint that would work; your authentication information would be protected. However neither asymmetric key crypto tools nor the certificate formats support such a use because it doesn't provide any benefit over a symmetric key cipher with a pre-shared secret.
不多。 它允许所有证书具有单一规范。 我们真正可以做的一件事是在 X.509v3 规范中提供另一种选择。
尽管如此，我还是可以想到一些其他原因，这些原因并不是真正必要的，但它们可能很方便：
自签名证书可以是根/CA 证书或根/叶证书。 在这两种情况下，都需要明确信任证书。
请注意，我创建的嵌入式实现仅在签名验证后接受证书，然后仅存储公钥和收到的证书的所需部分，这表明在验证证书后通常不再需要签名（日期和 CRL 验证）等等当然是另一回事）。
Not much. It allows all certificates to have a single specification. One thing that we can really do without is having another option within the X.509v3 specificiations.
Still, I can think of a few other reasons that are not really necessary but they could be handy:
Self signed certificates can either be root / CA certificates or root / leaf certificates. In both cases the certs need to be trusted explicitly.
Do note that I created embedded implementations that simply accepted certs after signature verification and then only stored the public key and required parts of the received certificates, showing that the signature is often not needed anymore after the certificate has been verified (date & CRL validation etc. is another matter of course).
两者之间的区别在于谁运行程序来生成证书。 某个大公司或某个乔在他的客厅里。 整个“签名证书”都是无稽之谈。 证书允许您加密数据，但向您出售产品的大公司会让您相信这意味着可信度和身份。 加密并不能保证身份，更重要的是，您可以信任发起者。 即使假设他们有 100% 的善意，只要看看新闻就知道了。 今年有多少大公司发生数据泄露事件？
我自签名了自己的证书，这样我就可以加密我的服务器和任何用户之间的网络流量。 我认为所有流量都应该加密，因为没有第三方能够看到您所做的事情。 我相信您应该对隐私有合理的期望。 你永远不应该完全信任任何人，尤其是那些想卖给你东西的人。
The difference between the two is who ran the program to generate the certificate. Some big corporation or some joe in his living room. The whole 'signed certificate' business is nonsense. A certificate allows you to encrypt data but large companies with something to sell you would have you believe that implies trustworthiness and identity. Encryption does not guarantee identity, and even more importantly, that you can trust the originator. Even assuming they have 100% good intentions just look in the news. How many big corporations have had data breaches this year?
I self signed my own certificate so I could encrypt the web traffic between my server and any users. I believe all traffic should be encrypted because no third party should be able to see what you do. I believe you should have a reasonable expectation of privacy. You should never completely trust anyone, particularly anyone who wants to sell you something.