I have stepped on this pit before. I have forgotten how to practice, but I still remember this principle. Roughly explain:
The browser's installation package stores some of the root certificates (public keys) that it trusts.
For security, certificate issuers usually store the private keys corresponding to these root certificates in an absolutely disconnected vault. These root private keys are used in the vault to issue some "intermediate" certificates, and the private keys of these intermediate certificates have the authority to issue the next level certificate. These intermediate private keys are installed on online servers to earn money by issuing website certificates. Once these servers are hacked, the publisher can issue a revocation order using the physically isolated root certificate private key in the vault to eliminate the trust of these intermediate certificates without having to completely distrust the publisher's root certificate. Sign a new intermediate issuance certificate, and you will be a good man who can make money.
Here comes the question.
The browser only recognizes the root certificate. For the certification of the intermediate certificate, you (the website) have to issue your own certificate.
A properly configured HTTPS website should include the full certificate chain in the certificate.
For example, use the openssl s_client -connect www.wosign.com:443 command to view Wosign's own website configuration.
The rest of the content can be ignored, just look at the Certificate chain paragraph:
---
Certificate chain
0 s:/1.3.6.1.4.1.311.60.2.1.3=CN/1.3.6.1.4.1.311.60.2.1.2=Guangdong/1.3.6.1.4.1.311.60.2.1.1=Shenzhen/businessCategory=Private Organization/serialNumber=440301103308619/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82/postalCode=518067/street=\xE6\xB7\xB1\ xE5\x9C\xB3\xE5\xB8\x82\xE5\x8D\x97\xE5\xB1\xB1\xE5\x8C\xBA\xE5\x8D\x97\xE6\xB5\xB7\xE5\xA4\xA7\xE9\x81\x931057\xE5\x8F\xB7\xE7\xA7\x91\xE6\x8A\x80\xE5\xA4\xA7\xE5\ x8E\xA6\xE4\xBA\x8C\xE6\x9C\x9FA\xE6\xA0\x8B502#/O=WoSign\xE6\xB2\x83\xE9\x80\x9A\xE7\x94\xB5\xE5\xAD\x90\xE8\xAE\xA4\xE8\xAF\x81\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\ xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/CN=www.wosign.com
i:/C=CN/O=WoSign CA Limited/CN=WoSign Class 4 EV Server CA
1 s:/C=CN/O=WoSign CA Limited/CN=WoSign Class 4 EV Server CA
i:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
2 s:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
0, 1, and 2 are the serial numbers of each level of certificate in the certificate chain. 0 is the certificate used by the website to be verified. Its CN should correspond to the website domain name.
After each serial number, the line starting with s refers to the certificate, and the line starting with i refers to who issued the certificate.
It can be seen that the CN of 0 contains a suspected Chinese domain name and an English domain www.wosign.com. It is issued by WoSign CA Limited/CN=WoSign Class 4 EV Server CA.
A certificate of 1 is the issuer of 0. 1 itself is issued by another certificate, the Certification Authority of WoSign.
Let's look at the next level, 2. It says that the Certification Authority of WoSign is issued by StartCom (haha, it turns out to be a subcontractor!). ）
So after looking at it at such a level, the browser says, oh, I know the issuer of 2, and it is mentioned in the installation package, StartCom. Correct signature and validation, so trust 2. Then you should also trust 1 issued by 2 and 0 issued by 1. So this website can be trusted.
－－
However, if the website is configured to contain only itself in the CRT file and not a certificate chain that is complete enough to be verified by the browser's built-in data, it may be rejected by the browser. Like what
openssl s_client -connect touko.moe:443
---
Certificate chain
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Free SSL Certificate G2
---
There is only 0 in one group. Description The touko.moe in line s is issued by WoSign CA Free SSL Certificate G2 in line i. It's gone.
This is the most amazing thing about this pitfall: it is not always true whether the browser fails to verify at this point. There are 2 situations:
A. I have never seen this i since the browser was installed. Then the validation fails.
B. If the browser has seen and verified i before, then the verification will be successful.
Usually the administrator will go to the https website of the certificate issuer to buy the certificate, and the browser will verify it, and then cache all the intermediate certificates that are successfully verified, saving time in the future. When the administrator (mistakenly) configured his website and went to browse the test, he would not encounter any problems at all. Because his browser already recognizes this intermediate certificate.
However, many users may not have visited other properly configured websites issued by this intermediate certificate. Therefore, validation fails because it cannot find a trusted issuer.
It is comparable to the exhaust emission control of Volkswagen diesel vehicles. Everything was fine when checked. As soon as they get outside, they put poison.
EDIT:How to fix ...... It is probably to add the SSLCertificateChainFile setting when configuring the server, and use the bundle file provided by the certificate issuer's website (the file contains a bunch of intermediate certificates to establish the connection between your certificate and a high-trust certificate).
|
Posted on 8/15/2017 9:08:39 PM
|
|
|
