blocks|key|360631|text|客户端具有SSL证书颁发机构的公钥的预先设定的存储区。必须有一个信任链，从服务器的证书到中间授权机构，直到一个所谓的“根”证书，才能使服务器被信任。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360632|您可以检查和/或更改受信任机构的列表。通常，您这样做是为了为您知道您信任的地方当局添加证书-例如您工作的公司或您就读的学校或其他不信任的机构。|360633|根据您使用的客户端的不同，预置列表可能会有所不同。大型SSL证书供应商确保他们的根证书可以在所有主要浏览器($$$)中使用。|360634|除非攻击者拥有受信任根证书的私钥，否则中间人攻击是“不可能的”。由于相应的证书被广泛使用，这样的私钥的暴露通常会对eCommerce的安全性产生严重的影响。正因为如此，这些私钥受到非常非常严密的保护。|360635|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The client has a pre-seeded store of SSL certificate authorities' public keys. There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called "root" certificates in order for the server to be trusted.

You can examine and/or alter the list of trusted authorities. Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not.

The pre-seeded list can vary depending on which client you use. The big SSL certificate vendors insure that their root certs are in all the major browsers ($$$).

Monkey-in-the-middle attacks are "impossible" unless the attacker has the private key of a trusted root certificate. Since the corresponding certificates are widely deployed, the exposure of such a private key would have serious implications for the security of eCommerce generally. Because of that, those private keys are very, very closely guarded.

blocks|key|3150297|text|这里有一个非常简单的解释：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150298|3150299|您的web浏览器将下载web服务器的证书，其中包含web服务器的公钥。此证书使用受信任证书的私钥签名，authority.|ordered-list-item|3150300|Your+web浏览器随附所有主要证书颁发机构的公钥。它使用此公钥来验证web服务器的证书是否确实由受信任的证书颁发机构签署。|3150301|证书包含web服务器的域名和/或ip地址。您的web浏览器与证书颁发机构确认证书中列出的地址就是它打开的HTTP浏览器生成的共享对称密钥，该对称密钥将用于加密此连接上的connection.|3150302|Your流量；这比使用公钥/私钥加密所有内容要高效得多。浏览器使用web服务器的公钥对对称密钥进行加密，然后将其发回，从而确保只有web服务器可以对其进行解密，因为只有web服务器具有其私钥。|3150303|3150304|请注意，证书颁发机构(CA)对于防止中间人攻击至关重要。但是，即使是未签名的证书也会阻止其他人被动地监听您的加密流量，因为他们无法访问您的共享对称密钥。|3150305|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|V|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

Here is a very simplified explanation:

<ol>
<li>Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.</li>
<li>Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.</li>
<li>The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.</li>
<li>Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.</li>
</ol>

Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.

blocks|key|3150393|text|值得注意的是，除了购买证书(如上所述)外，您还可以免费创建自己的证书；这称为“自签名证书”。自签名证书和购买的证书之间的区别很简单:购买的证书是由您的浏览器已经知道的证书颁发机构签名的。换句话说，您的浏览器可以轻松地验证购买的证书的真实性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150394|不幸的是，这导致了一种常见的误解，即自签名证书天生就没有GoDaddy和Verisign等商业CA销售的证书那么安全，并且如果使用它们，您必须忍受浏览器警告/异常；这是不正确的。|offset|length|style|BOLD|3150395|如果您安全地分发自签名证书(或CA证书，如bobince建议的那样)，并将其安装在将使用您的站点的浏览器中，则它与购买的证书一样安全，并且不容易受到中间人攻击和证书伪造。显然，这意味着只有少数人需要安全地访问您的站点(例如，内部应用程序、个人博客等)时，这才是可行的。|3150396|entityMap^0|0|2A|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It's worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.

Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.

If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).

blocks|key|361511|text|你说过的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361512|361513|浏览器从该证书获取证书的颁发者信息，然后使用该信息联系颁发者，并以某种方式比较证书的有效性。|blockquote|361514|361515|361516|客户端不需要与发行者进行核对，因为有两件事：|361517|361518|所有浏览器都预先安装了所有主要can公钥的列表|ordered-list-item|361519|证书已签名，该签名本身就足以证明证书是有效的，因为客户端可以自己确保该证书是可信的，而无需联系颁发者的服务器。这就是非对称加密的美妙之处。|361520|361521|请注意，2。没有1是不能完成的。|361522|这在我不久前写的这篇big+diagram中得到了更好的解释|offset|length|361523|(跳到“什么是签名?”在底部)|361524|​|361525|📷|atomic|361526|361527|entityMap|0|LINK|mutability|MUTABLE|url|https://imgur.com/gallery/5T2fJsG/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/7649e2d7326c9068d90c948e3172c0fc.png|imageAlt^0|0|0|0|0|0|0|0|0|0|0|0|A|B|0|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1K|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1N|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|1Q|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1S|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1T|8|@]|9|@$U|1U|V|1V|1|1W]]|A|$]]|$1|W|3|X|5|6|7|1X|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|10|3|11|5|12|7|1Z|8|@]|9|@$U|20|V|21|1|22]]|A|$]]|$1|13|3|Z|5|6|7|23|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|24|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]|1C|$5|1D|18|1E|A|$1F|1G|1H|-4]]]]

You said that 

<blockquote>
 the browser gets the certificate's issuer information from that
 certificate, then uses that to contact the issuerer, and somehow
 compares certificates for validity.
</blockquote>

The client doesn't have to check with the issuer because two things : 

<ol>
<li>all browsers have a pre-installed list of all major CAs public keys</li>
<li>the certificate is signed, and that signature itself is enough proof that the certificate is valid because the client can make sure, by his own, and without contacting the issuer's server, that that certificate is authentic. That's the beauty of asymmetric encryption.</li>
</ol>

Notice that 2. can't be done without 1. 

This is better explained in this <a href="https://imgur.com/gallery/5T2fJsG/" rel="noreferrer">big diagram</a> I made some time ago 

(skip to "what's a signature ?" at the bottom)

<img src="https://i.imgur.com/F4Zzecf.png" alt="blob">

blocks|key|3363427|text|如果你有更多的技术头脑，这个网站可能是你想要的：http://www.zytrax.com/tech/survival/ssl.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3363428|警告:兔子洞很深:)。|3363429|entityMap|0|LINK|mutability|MUTABLE|url|http://www.zytrax.com/tech/survival/ssl.html^0|O|18|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

if you're more technically minded, this site is probably what you want: <a href="http://www.zytrax.com/tech/survival/ssl.html" rel="noreferrer">http://www.zytrax.com/tech/survival/ssl.html</a>

warning: the rabbit hole goes deep :).

blocks|key|359445|text|我知道下面的内容很长，但它很详细，但也足够简单。仔细阅读，我保证你会发现这个话题并不那么复杂。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359446|首先，任何人都可以创建2个密钥。一个用于加密数据，另一个用于解密数据。前者可以是私钥，后者可以是公钥，VICERZA。|359447|其次，用最简单的术语来说，证书颁发机构(CA)为您提供创建证书的服务。多么?它们使用某些值(CA的颁发者名称、服务器的公钥、公司名称、域等)他们使用SUPER+DUPER超级安全的秘密私钥对这些数据进行加密。这个加密数据的结果是一个签名。|359448|所以现在CA会给你发回一个证书。证书基本上是一个包含前面提到的值(CA的颁发者名称、公司名称、域、服务器的公钥等)的文件，包括签名(即后一值的加密版本)。|359449|现在，说到这里，这里有一个非常重要的部分需要记住:你的设备/操作系统(Windows，Android，等等)几乎保留了所有主要/受信任的CA及其公钥的列表(如果您认为这些公钥用于解密证书中的签名，您是正确的！)。|offset|length|style|BOLD|359450|好的，如果你读了上面的内容，这个连续的例子现在将是轻而易举的：|359451|359452|Example-Company要求Example-CA为它们创建一个certificate.|ordered-list-item|359453|Example-CA，使用他们的超级私钥来签署此证书，并给出Example-Company+certificate.|359454|Tomorrow，internet-user-Bob使用Chrome/Firefox/等浏览https://example-company.com。如今，大多数浏览器都希望从服务器返回证书。|359455|浏览器从example-company.com获取证书。证书上说它是由Example-CA颁发的。碰巧Bob的操作系统在其信任CA的列表中已经有Example-CA，所以浏览器会得到Example-CA的公钥。记住:这一切都发生在Bob的电脑/手机等设备上，而不是通过网络。|359456|，所以现在浏览器会解密证书中的签名。最后，浏览器将解密的值与证书本身的内容进行比较。如果内容匹配，则表示签名为VALID!|359457|+|359458|为什么？想想看，只有这个公钥才能以这样一种方式解密签名，即内容看起来像私钥加密它们之前的样子。|359459|那中间人的攻击呢？|359460|这是创建上述标准的主要原因之一(如果不是主要原因)。|359461|假设hacker-Jane截取了internet-user-Bob的请求，并用她自己的证书进行回复。然而，hacker-Jane仍然非常小心地在证书中声明颁发者是Example-CA。最后，hacker-Jane记得她必须在证书上包含签名。但是Jane使用什么密钥来签名(即创建证书主要内容的加密值)证书？|359462|因此，即使hacker-Jane用她自己的密钥签署了证书，您也会看到接下来会发生什么。浏览器会说：“好的，这个证书是由Example-CA颁发的，让我们用Example-CA的公钥来解密签名”。解密后，浏览器会发现证书内容根本不匹配。因此，浏览器向用户发出非常明确的警告，并表示它不信任该连接。|359463|entityMap|0|LINK|mutability|MUTABLE|url|https://example-company.com/^0|0|0|0|0|D|5|20|2|2Q|6|0|0|0|0|0|1A|R|0|0|0|0|0|0|1B|0|0|9|0|0|Q|0|0|49|0|0|43|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1P|8|@$J|1Q|K|1R|L|M]|$J|1S|K|1T|L|M]|$J|1U|K|1V|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1W|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1Y|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|1Z|8|@]|9|@]|A|$]]|$1|V|3|W|5|S|7|20|8|@]|9|@$J|21|K|22|1|23]]|A|$]]|$1|X|3|Y|5|S|7|24|8|@]|9|@]|A|$]]|$1|Z|3|10|5|S|7|25|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|26|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|27|8|@$J|28|K|29|L|M]]|9|@]|A|$]]|$1|15|3|16|5|6|7|2A|8|@$J|2B|K|2C|L|M]]|9|@]|A|$]]|$1|17|3|18|5|6|7|2D|8|@$J|2E|K|2F|L|M]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2G|8|@$J|2H|K|2I|L|M]]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2J|8|@$J|2K|K|2L|L|M]]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|1K]]]]

<h2>I KNOW THE BELOW IS LONG, BUT IT IS DETAILED, YET SIMPLIFIED ENOUGH. READ CAREFULLY AND I GUARANTEE YOU'LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED.</h2>
First of all, anyone can create 2 keys. One to encrypt data, and another to decrypt data. The former can be a private key, and the latter a public key, AND VICERZA.
Second of all, in simplest terms, a Certificate Authority (CA) offers the service of creating a certificate for you. How? They use certain values (the CA's issuer name, your server's public key, company name, domain, etc.) and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data. The result of this encrypted data is a SIGNATURE.
So now the CA gives you back a certificate. The certificate is basically a file containing the values previously mentioned (CA's issuer name, company name, domain, your server's public key, etc.), INCLUDING the signature (i.e. an encrypted version of the latter values).
Now, with all that being said, here is a REALLY IMPORTANT part to remember: your device/OS (Windows, Android, etc.) pretty much keeps a list of all major/trusted CA's and their PUBLIC KEYS (if you're thinking that these public keys are used to decrypt the signatures inside the certificates, YOU ARE CORRECT!).
Ok, if you read the above, this sequential example will be a breeze now:
<ol>
<li>Example-Company asks Example-CA to create for them a certificate.</li>
<li>Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate.</li>
<li>Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to <a href="https://example-company.com" rel="noreferrer">https://example-company.com</a>. Most, if not all, browsers nowadays will expect a certificate back from the server.</li>
<li>The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire.</li>
<li>So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!</li>
</ol>
Why? Think about it, only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them.
<h2>How about man in the middle attacks?</h2>
This is one of the main reasons (if not the main reason) why the above standard was created.
Let's say hacker-Jane intercepts internet-user-Bob's request, and replies with her own certificate. However, hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA. Lastly, hacker-Jane remembers that she has to include a signature on the certificate. But what key does Jane use to sign (i.e. create an encrypted value of the certificate main contents) the certificate?????
So even if hacker-Jane signed the certificate with her own key, you see what's gonna happen next. The browser is gonna say: &quot;ok, this certificate is issued by Example-CA, let's decrypt the signature with Example-CA's public key&quot;. After decryption, the browser notices that the certificate contents don't match at all. Hence, the browser gives a very clear warning to the user, and it says it doesn't trust the connection.

What is the series of steps needed to securely verify a ssl certificate? My (very limited) understanding is that when you visit an https site, the server sends a certificate to the client (the browser) and the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity. 

<ul>
<li>How exactly is this done? </li>
<li>What about the process makes it immune to man-in-the-middle attacks?</li>
<li>What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks, so everything "looks" secure?</li>
</ul>

How are ssl certificates verified?

非对称加密

对称加密

服务器

Android

Windows

安全地验证ssl证书需要执行哪一系列步骤？我(非常有限)的理解是，当您访问https站点时，服务器将证书发送到客户端(浏览器)，浏览器从该证书中获取证书的颁发者信息，然后使用该信息联系颁发者，并以某种方式比较证书的有效性。这到底是怎么做的？如何使其免受中间人攻击？防止一些随机的人设置自己的验证服务以用于中间人攻击，因此...

问如何验证ssl证书？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何验证ssl证书？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何验证ssl证书？
EN