Jag har trampat på den här gropen förut. Jag har glömt hur man praktiserar, men jag minns fortfarande denna princip. Förklara ungefär:
Webbläsarens installationspaket lagrar några av de rotcertifikat (publika nycklar) som den litar på.
För säkerhet lagrar certifikatutgivare vanligtvis de privata nycklarna som motsvarar dessa rotcertifikat i ett helt frånkopplat valv. Dessa rotprivata nycklar används i valvet för att utfärda vissa "mellanliggande" certifikat, och de privata nycklarna till dessa mellanliggande certifikat har befogenhet att utfärda nästa nivå av certifikat. Dessa mellanliggande privata nycklar installeras på onlineservrar för att tjäna pengar genom att utfärda webbplatscertifikat. När dessa servrar har hackats kan utgivaren utfärda en återkallelseorder med hjälp av den fysiskt isolerade privata nyckeln till rotcertifikatet i valvet för att eliminera förtroendet för dessa mellanliggande certifikat utan att helt misstro utgivarens rotcertifikat. Skriv under ett nytt mellanliggande utfärdandecertifikat, så blir du en bra man som kan tjäna pengar.
Här kommer frågan.
Webbläsaren känner bara igen root-certifikatet. För certifiering av mellanliggande certifikat måste du (webbplatsen) utfärda ditt eget certifikat.
En korrekt konfigurerad HTTPS-webbplats bör inkludera hela certifikatkedjan i certifikatet.
Till exempel kan du använda openssl s_client -connect www.wosign.com:443-kommandot för att se Wosigns egen webbplatskonfiguration.
Resten av innehållet kan ignoreras, titta bara på stycket om certifikatkedjan:
---
Certifikatkedja
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=Privat Organisation/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\xxAD\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=Certifieringsmyndighet för WoSign
2 s:/C=CN/O=WoSign CA Limited/CN=Certifieringsmyndighet för WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
0, 1 och 2 är serienumren för varje certifikatnivå i certifikatkedjan. 0 är certifikatet som används av webbplatsen för att verifieras. Dess CN bör motsvara webbplatsens domännamn.
Efter varje serienummer avser raden som börjar på s certifikatet, och raden som börjar på i avser vem som utfärdade certifikatet.
Det kan ses att CN på 0 innehåller ett misstänkt kinesiskt domännamn och en engelsk domän www.wosign.com. Den ges ut av WoSign CA Limited/CN=WoSign Class 4 EV Server CA.
Ett certifikat på 1 är utfärdaren av 0. 1 utfärdas av ett annat certifikat, WoSigns certifieringsmyndighet.
Låt oss titta på nästa nivå, 2. Det står att WoSigns certifieringsmyndighet utfärdas av StartCom (haha, det visar sig vara en underleverantör!). ）
Så efter att ha tittat på det på den nivån säger webbläsaren, åh, jag känner till utgivaren av 2, och det nämns i installationspaketet, StartCom. Korrekt signatur och validering, så lita på 2. Då bör du också lita på 1 utfärdad av 2 och 0 utgiven av 1. Så den här webbplatsen kan litas på.
－－
Om webbplatsen däremot är konfigurerad att endast innehålla sig själv i CRT-filen och inte i en certifikatkedja som är tillräckligt komplett för att verifieras av webbläsarens inbyggda data, kan den avvisas av webbläsaren. Som vad
OpenSSL s_client -connect touko.moe:443
---
Certifikatkedja
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Gratis SSL-certifikat G2
---
Det finns bara 0 i en grupp. Beskrivning Touko.moe i rad s utfärdas av WoSign CA Gratis SSL-certifikat G2 i rad i. Den är borta.
Det här är det mest fantastiska med denna fallgrop: det är inte alltid sant om webbläsaren misslyckas med att verifiera vid det här laget. Det finns två situationer:
S. Jag har aldrig sett detta sedan webbläsaren installerades. Sedan misslyckas valideringen.
B. Om webbläsaren har sett och verifierat i tidigare, kommer verifieringen att lyckas.
Vanligtvis går administratören till https-webbplatsen för certifikatutgivaren för att köpa certifikatet, och webbläsaren verifierar det och cachelagrar sedan alla mellanliggande certifikat som verifierats framgångsrikt, vilket sparar tid i framtiden. När administratören (av misstag) konfigurerade sin webbplats och gick för att bläddra i testet, stötte han inte på några problem alls. För att hans webbläsare redan känner igen detta mellanliggande certifikat.
Många användare kan dock ha saknat andra korrekt konfigurerade webbplatser som utfärdats av detta mellanliggande certifikat. Därför misslyckas valideringen eftersom den inte kan hitta en betrodd utgivare.
Den är jämförbar med avgaskontrollen från Volkswagens dieselfordon. Allt var bra när jag kontrollerade. Så fort de kommer ut tillsätter de gift.
REDIGERING: Hur fixar man ...... Det är troligen att lägga till SSLCertificateChainFile-inställningen när servern konfigureras, och använda paketfilen som tillhandahålls av certifikatutgivarens webbplats (filen innehåller en massa mellanliggande certifikat för att etablera anslutningen mellan ditt certifikat och ett högförtroendecertifikat).
|
Publicerad på 2017-08-15 21:08:39
|
|
|
