如何识别假SSL证书？
我已经阅读了 SSL 协议，现在我知道它如何加密数据。但有件事我无法理解。使用 SSL ，您可以确定正在向正确的服务器发送数据并从正确的服务器获取数据。但如何？
我的意思是，如果我创建一个假证书并将其发送给特殊网站的请求，浏览器（或其他程序）如何检测假证书？
编辑：我并不是要创建自签名证书。我的意思是，如果我创建一个证书，其颁发者和主题等是真正的证书，那么有人如何验证我的证书！ （唯一不真实的是公钥和签名）
I've read about SSL protocol and now, I know how it encrypts data. But there is something I couldn't understand. With SSL , you're sure you're sending data to and getting data from correct server. But how?
I mean if I create a fake certificate and send it for requests of special website, how do browsers ( or other programs) detect the fake certificate?
Edit: I didn't mean to create a self-signed certificate. I meant how can someone validate my certificate if I create a certificate that its issuer and subject ,etc are something to real certificate! (the only things that are not real is Public key & signature)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
TL;DR 摘要：
服务器证书的有效性通过以下方式建立：
说明
假设您要连接到 https://mail .google.com（您可以尝试这在您的浏览器中显示！）。
（真实）服务器将使用颁发给
mail.google.com的证书进行响应，即在证书的“主题”字段中，您将找到通用名称 (CN)“mail.google” .com' - 参见。 RFC 5280 有关证书字段的详细信息。主题链接到站点 URL 的事实对于整个模型的安全性非常重要，并且您的 TLS 实现会主动检查它（“主机名验证”），因为否则就会有 Man-In- 的空间中间派攻击。即，有人可以获取其他有效的证书并冒充 mail.google.com，而您却没有注意到它。除了主机名验证之外，您的 TLS 实施还将检查证书的“有效性”。整个过程相当复杂，确实包括检查证书的可信度，但此外还会检查许多其他事情，稍后会详细介绍。
如果您在浏览器中查看 Google Mail 的证书，您会注意到实际上显示了三个证书：
模型是有一些（不幸的是，不再那么少了）受信任的根证书颁发机构（“根 CA”），您可以自己选择，也可以（更有可能）使用盲目信任的软件（例如浏览器）预先配置它们。这些可信机构构成了“PKI”（公钥基础设施）整个信任模型的锚。基本思想是受信任的实体可以向其他机构颁发证书并授予他们再次颁发证书的权限（这些机构称为中间证书机构）。中间CA可以再次递归地应用该过程直到某一点，实际最终实体证书和根CA证书之间的中间CA的数量通常是有限的。
在某一时刻，中间 CA 将向“最终实体”（在我们的示例中为“mail.google.com”）颁发证书。现在颁发证书的过程实际上意味着请求证书的一方将首先创建公钥/私钥对，并使用它们来验证发送到证书颁发机构的证书请求。颁发机构通过使用非对称算法（例如 RSA）使用其自己的私钥“签名”该证书，并通过在新证书中额外包含请求方的公钥，为从属实体（中间 CA 或最终实体）创建证书。生成的证书。根CA拥有所谓的自签名证书，即根CA是唯一可以签署自己的证书并包含自己的公钥的机构。当然，私钥始终处于隐藏状态。
证书颁发过程的递归性质意味着对于每个最终实体证书，都有一种独特的方式来建立通向根证书颁发机构的证书“链”。现在，当您在尝试连接到受 TLS 保护的站点时收到最终实体证书时，将递归应用以下过程，直到您最终获得根 CA 证书：
如果所有检查都是肯定的，您最终将得到一个自签名的证书，即主题也是颁发者（例如我们示例中的 VeriSign 证书）。现在，您必须验证的最后一件事是该证书是否属于您盲目信任的证书：如果是，则一切正常并且连接将成功，如果不是，则连接尝试将被拒绝。
好像这还不够复杂，到目前为止描述的检查并不能处理曾经有效的证书突然变得流氓的情况，例如证书被盗或私钥被泄露的情况（想想 Comodo 和 DigiNotar）。在这些情况下，正常的程序是“撤销”那些变坏的证书，也就是说，您希望从一个不同的时间点开始将它们标记为无效（无论如何它们都会在某个时间点过期，但在该期间的剩余时间内）它们应已被标记为无效）。对于这些情况，CA 可以颁发 CRL（声明为无效的证书目录）或 OCSP 响应（一个或极少数情况下一组证书的信息），为客户提供给定证书是否已被标记为无效的信息或不。需要检查链中所有证书的吊销状态，如果其中一个证书被标记为无效，则最终实体证书不可信，连接也必须被拒绝。
TL;DR summary:
Validity of a server certificate is established by:
Explanation
Let's assume you want to connect to https://mail.google.com (you can try this out in your browser!).
The (real) server will respond with a certificate that is issued to
mail.google.com, i.e. in the 'Subject' field of the certificate you will find the Common Name (CN) 'mail.google.com' - cf. RFC 5280 for details on the fields of certificates. The fact that the subject is linked to the site URL is very important for the security of the whole model, and it is actively checked by your TLS implementation ("host name verification"), because otherwise there would be room for Man-In-The-Middle attacks. I.e. somebody could acquire an otherwise valid certificate and impersonate mail.google.com without you taking any notice of it.In addition to the host name verification, your TLS implementation will also check the "validity" of the certificate. The whole procedure is rather complex and does include checking the trustworthiness of the certificate, but additionally a lot of other things will be checked, more on that in a minute.
If you view Google Mail's certificate in your browser, you will notice that there are actually three certificates shown:
The model is that there are a few (well, unfortunately not so few anymore) trusted root certificate authorities ("root CAs") that either you could choose on your own or (more likely) that come preconfigued with your software (e.g. browser) that are blindly trusted. These trusted authorities form the anchors of the entire trust model of "PKI" (Public Key Infrastructure). The basic idea is that the trusted entities may issue certificates to other authorities and grant them permission to again issue certificates (these authorities are called intermediate certificate authorities). The intermediate CAs may again recursively apply this procedure up to a certain point, the number of intermediate CAs between an actual end entity certificate and a root CA certificate is generally limited.
At one point, an intermediate CA will issue certificates to an "end entity" ("mail.google.com" in our example). Now the process of issuing a certificate actually means that the party requesting a certificate will create a public/private key pair first, and use them to authenticate a certificate request that is sent to the certificate authority. The issuing authority creates a certificate for the subordinate entity (either intermediate CA or end entity) by "signing" that certificate using its own private key using an asymmetric algorithm such as RSA and by additionally including the public key of the requesting party within the newly generated certificate. The root CA possesses a so called self-signed certificate, i.e. the root CA is the only authority that may sign their own certificate and include their own public key. The private key remains hidden at all times, of course.
The recursive nature of the certificate issuing process implies that for each end entity certificate there is a unique way of establishing a "chain" of certificates that leads up to a root certificate authority. Now when you are presented with an end entity certificate while trying to connect to a TLS-secured site, the following procedure will be applied recursively until you end up with a root CA certificate:
If all checks were positive, you will ultimately end up with a certificate being self-signed, i.e. where the subject is also the issuer (such as the VeriSign certificate in our example). Now the last thing you have to verify is whether this certificate is among those that you blindly trust: if it is, all is well and the connection will succeed, if it is not, the connection attempt will be rejected.
As if this were not complicated enough already, the checks described so far do not handle cases where once valid certificates suddenly become rogue, examples being cases where a certificate is stolen or private keys are compromised (think of Comodo and DigiNotar). In these cases, the normal procedure is to "revoke" those certificates gone bad, that is you want to mark them as being invalid starting from a distinct point in time (they will expire at some point anyway, but for the remainder of that period they shall already be marked as invalid). For these cases, CAs have the possibility to issue CRLs (a catalog of certificates declared as invalid) or OCSP responses (information for one or in rare cases a set of certificates) that provides clients with information whether a given certificate has been marked as invalid or not. The revocation status needs to be checked for all certificates in a chain, should one of them be marked as invalid then the end entity certificate cannot be trusted and the connection must be rejected as well.
SSL 证书由证书颁发机构 (CA) 签名，该机构是用户已经信任的机构（或更有可能的是，设计操作系统的人信任）。
CA 使用公钥加密对证书进行数字签名。基本解释是，CA 有一个“私钥”和一个众所周知的“公钥”。通过一些我不明白的数学，CA 可以使用其私钥创建签名，该签名可以轻松地使用其公钥进行验证（但公钥不能用于创建新签名）。
当您从服务器获取 SSL 证书时，您将获得服务器的公钥以及来自 CA 的签名，表明该证书有效（以及一些其他信息）。如果您了解并信任该 CA，则可以检查签名并确定其是否有效。您还可以使用证书吊销列表来确保它未被吊销。
所以基本上，您可以识别出错误的 SSL 证书，因为它不是由您信任的证书颁发机构签名的。
SSL certificates are signed by a certificate authority (CA), which is someone the user already trusts (or more likely, the people who designed their operating system trusts).
The CA digitally signs the certificate using public key encryption. The basic explanation is that the CA has a "private key", and a "public key" that everyone knows. Via some math I don't understand, the CA can create a signature using its private key which can easily be verified with its public key (but the public key can't be used to create a new signature).
When you get an SSL certificate from a server, you get the server's public key, and a signature from a CA saying that it's valid (along with some other info). If you know and trust that CA, you can check the signature and determine if it's valid. You can also use a certificate revocation list to make sure it wasn't revoked.
So basically, you can recognize a bad SSL certificate because it isn't signed by a certificate authority that you trust.
您创建的任何假证书都将是自签名证书。
当连接到具有自签名证书的网站时，浏览器将显示巨大的可怕警告用户会立即忽略该警告。
为了避免警告，您需要由浏览器认可的证书颁发机构签名的证书信托公司，例如 VeriSign。
这些公司希望确保您确实拥有他们所签署的证书的域名。
回复：编辑：只有从受信任的 CA 签署了非自签名证书，您才能创建该证书。
他们将拒绝签署不同主题的证书。
Any fake certificate you create will be a self-signed certificate.
The browser will display big scary warnings when connecting to a site with a self-signed certificate which the user will promptly ignore.
In order to avoid warnings, you need a certificate signed by a certificate authority that the browser trusts, such as VeriSign.
These companies will hopefully make sure that you actually own the domain for the certificate they're signing.
Re: Edit: You can only create a non-self-signed certificate if you get it signed from a trusted CA.
They will refuse to sign a certificate for a different subject.
根据我的理解，过程是：
服务器公钥证书（由受信任的CA使用其私钥加密的所有信息）服务器公钥的哈希值（使用sha1和sha256）服务器公钥的哈希值与证书存储的哈希值，如果不是相同的浏览器将阻止网站证书中允许的域与域进行比较，如果不允许，如果不是相同的浏览器将阻止网站证书的有效日期和您的日期，如果无效，浏览器将阻止网站。要伪造这一点，您需要：
因此，如果您看到地址栏中的挂锁几乎总是安全的。
Process from my understanding:
servers public keycertificate(all information encrypted by trusted CA with their private key)sha1andsha256) theservers public keyservers public keywithcertificatestored hash, if not same browser will block sitecertificateand the domain, if not allowed, if not same browser will block sitecertificateand your date, if not valid browser will block site.To fake this you would either need to:
So if you see a padlock in the address bar you are almost always safe.
证书之所以有效，是因为它们遵循信任链。证书具有一系列受信任的一个或多个颁发者；这条链条是它发挥作用的支柱。浏览器和几乎所有 SSL 证书库都会执行此链检查，或者至少提供选项。
自签名证书（或由以自签名证书结尾的链颁发的证书）将无法通过此检查。
Certificates work because they follow a chain of trust. Certificates have a chain of one or more issuers that are trusted; this chain is the backbone of why it works at all. Browsers and nearly all SSL certificate libraries do this chain check, or at least provide the option to.
Self-signed certificates (or those issued by chains that end in a self-signed certificate) would fail this check.