Ik ben eerder op deze put gestapt. Ik ben vergeten hoe ik moet oefenen, maar ik herinner me dit principe nog steeds. Leg het globaal uit:
Het installatiepakket van de browser slaat enkele van de rootcertificaten (publieke sleutels) op die het vertrouwt.
Voor beveiliging slaan certificaatuitgevers meestal de privésleutels die bij deze rootcertificaten horen op in een volledig losgekoppelde kluis. Deze root private keys worden in de kluis gebruikt om sommige "intermediaire" certificaten uit te geven, en de private keys van deze tussenliggende certificaten hebben de bevoegdheid om het certificaat van het volgende niveau uit te geven. Deze tussenliggende privésleutels worden op online servers geïnstalleerd om geld te verdienen door het uitgeven van websitecertificaten. Zodra deze servers zijn gehackt, kan de uitgever een intrekkingsbevel uitvaardigen met behulp van de fysiek geïsoleerde privésleutel van het rootcertificaat in de vault om het vertrouwen in deze tussenliggende certificaten te elimineren zonder het rootcertificaat van de uitgever volledig te wantrouwen. Teken een nieuw tussentijds uitgiftecertificaat en je wordt een goed mens die geld kan verdienen.
Hier komt de vraag.
De browser herkent alleen het rootcertificaat. Voor de certificering van het intermediate certificaat moet je (de website) je eigen certificaat afgeven.
Een correct geconfigureerde HTTPS-website zou de volledige certificaatketen in het certificaat moeten opnemen.
Gebruik bijvoorbeeld het openssl s_client -connect www.wosign.com:443 commando om de eigen websiteconfiguratie van Wosign te bekijken.
De rest van de inhoud kan worden genegeerd, kijk gewoon naar de paragraaf Certificaatketen:
---
Certificaatketen
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=Privé Organisatie/serienummer=440301103308619/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82/postcode=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\xxA4\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=Certificeringsautoriteit van WoSign
2 s:/C=CN/O=WoSign CA Limited/CN=Certificeringsautoriteit van WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
0, 1 en 2 zijn de serienummers van elk certificaatniveau in de certificaatketen. 0 is het certificaat dat door de website wordt gebruikt om te worden geverifieerd. De CN moet overeenkomen met de domeinnaam van de website.
Na elk serienummer verwijst de regel die met s begint naar het certificaat, en de regel die met i begint naar wie het certificaat heeft afgegeven.
Uit te zien is dat de CN van 0 een vermoedelijke Chinese domeinnaam en een Engels domein www.wosign.com bevat. Het wordt uitgegeven door WoSign CA Limited/CN=WoSign Class 4 EV Server CA.
Een certificaat van 1 is de uitgever van 0. 1 wordt zelf uitgegeven door een ander certificaat, de Certificeringsautoriteit van WoSign.
Laten we naar het volgende niveau kijken, 2. Er staat dat de certificeringsautoriteit van WoSign wordt uitgegeven door StartCom (haha, het blijkt een onderaannemer te zijn!). ）
Dus na zo'n bekeken manier zegt de browser: oh, ik ken de uitgever van 2, en het wordt genoemd in het installatiepakket, StartCom. Correcte handtekening en validatie, dus vertrouw 2. Dan moet je ook vertrouwen op 1 uitgegeven door 2 en 0 uitgegeven door 1. Dus deze website is te vertrouwen.
－－
Als de website echter is geconfigureerd om alleen zichzelf in het CRT-bestand te bevatten en niet in een certificaatketen die volledig genoeg is om door de ingebouwde browsergegevens te worden geverifieerd, kan deze door de browser worden afgewezen. Wat dan?
OpenSSL s_client -connect touko.moe:443
---
Certificaatketen
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Gratis SSL-certificaat G2
---
Er is maar 0 in één groep. Beschrijving De touko.moe in regel s wordt uitgegeven door WoSign CA Gratis SSL-certificaat G2 in regel i. Het is weg.
Dit is het meest verbazingwekkende aan deze valkuil: het is niet altijd waar of de browser op dit punt niet verifieert. Er zijn twee situaties:
A. Ik heb dit nooit meer gezien sinds de browser werd geïnstalleerd. Dan faalt de validatie.
B. Als de browser i eerder heeft gezien en geverifieerd, zal de verificatie succesvol zijn.
Meestal gaat de beheerder naar de https-website van de certificaatuitgever om het certificaat te kopen, en de browser verifieert het en cachet vervolgens alle tussenliggende certificaten die succesvol zijn geverifieerd, wat in de toekomst tijd bespaart. Wanneer de beheerder (per vergissing) zijn website configureerde en de test ging bekijken, kwam hij helemaal geen problemen tegen. Omdat zijn browser dit tussentijdse certificaat al herkent.
Veel gebruikers hebben echter mogelijk geen andere correct geconfigureerde websites bezocht die door dit tussentijdse certificaat zijn uitgegeven. Daarom faalt validatie omdat het geen vertrouwde uitgever kan vinden.
Het is vergelijkbaar met de uitlaatemissiecontrole van Volkswagen-dieselvoertuigen. Alles was in orde toen ik het controleerde. Zodra ze buiten zijn, doen ze gif.
EDIT: Hoe los je ...... Waarschijnlijk is het om de SSLCertificateChainFile-instelling toe te voegen bij het configureren van de server, en het bundelbestand te gebruiken dat door de website van de certificaatuitgever wordt geleverd (het bestand bevat een aantal tussenliggende certificaten om de verbinding tussen jouw certificaat en een high-trust certificaat tot stand te brengen).
|
Geplaatst op 15-08-2017 21:08:39
|
|
|
