Jeg har tråkket på denne gropen før. Jeg har glemt hvordan man praktiserer, men jeg husker fortsatt dette prinsippet. Forklar grovt:
Nettleserens installasjonspakke lagrer noen av rotsertifikatene (offentlige nøkler) som den stoler på.
For sikkerhet lagrer sertifikatutstedere vanligvis de private nøklene som tilsvarer disse rotsertifikatene i et helt frakoblet hvelv. Disse rotprivate nøklene brukes i hvelvet til å utstede noen "mellomliggende" sertifikater, og de private nøklene til disse mellomliggende sertifikatene har myndighet til å utstede neste nivå sertifikat. Disse mellomliggende private nøklene installeres på nettbaserte servere for å tjene penger ved å utstede nettsidesertifikater. Når disse serverne er hacket, kan utgiveren utstede en tilbakekallingsordre ved å bruke den fysisk isolerte private nøkkelen til rotsertifikatet i hvelvet for å eliminere tilliten til disse mellomliggende sertifikatene uten å måtte mistenke utgiverens rotsertifikat fullstendig. Signer et nytt mellomliggende utstedelsessertifikat, og du vil være en god mann som kan tjene penger.
Her kommer spørsmålet.
Nettleseren gjenkjenner kun rotsertifikatet. For sertifisering av mellomsertifikatet må du (nettsiden) utstede ditt eget sertifikat.
Et korrekt konfigurert HTTPS-nettsted bør inkludere hele sertifikatkjeden i sertifikatet.
For eksempel, bruk openssl s_client -connect www.wosign.com:443-kommandoen for å se Wosigns egen nettsidekonfigurasjon.
Resten av innholdet kan ignoreres, bare se på avsnittet om sertifikatkjeden:
---
Sertifikatkjede
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 Organisasjon/serienummer=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=Sertifiseringsmyndighet for WoSign
2 s:/C=CN/O=WoSign CA Limited/CN=Sertifiseringsmyndighet for WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
0, 1 og 2 er serienumrene til hvert sertifikatnivå i sertifikatkjeden. 0 er sertifikatet som brukes av nettstedet for å verifiseres. Dens CN skal tilsvare nettstedets domenenavn.
Etter hvert serienummer refererer linjen som starter med s til sertifikatet, og linjen som begynner med i refererer til hvem som utstedte sertifikatet.
Det kan sees at CN til 0 inneholder et mistenkt kinesisk domenenavn og et engelsk domene www.wosign.com. Den utstedes av WoSign CA Limited/CN=WoSign Class 4 EV Server CA.
Et sertifikat på 1 er utstederen av 0. 1 utstedes selv av et annet sertifikat, WoSigns sertifiseringsmyndighet.
La oss se på neste nivå, 2. Det står at sertifiseringsmyndigheten for WoSign er utstedt av StartCom (haha, det viser seg å være en underleverandør!). ）
Så etter å ha sett på det på et slikt nivå, sier nettleseren, å, jeg kjenner utstederen av 2, og det står nevnt i installasjonspakken, StartCom. Korrekt signatur og validering, så stol på 2. Da bør du også stole på 1 utstedt av 2 og 0 utstedt av 1. Så denne nettsiden kan stoles på.
－－
Men hvis nettstedet er konfigurert til kun å inneholde seg selv i CRT-filen og ikke i en sertifikatkjede som er komplett nok til å verifiseres av nettleserens innebygde data, kan det bli avvist av nettleseren. Som hva
OpenSSL s_client -connect touko.moe:443
---
Sertifikatkjede
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Gratis SSL-sertifikat G2
---
Det er bare 0 i én gruppe. Beskrivelse Touko.moe i linje s utstedes av WoSign CA Gratis SSL-sertifikat G2 i linje i. Den er borte.
Dette er det mest fantastiske med denne fallgruven: det er ikke alltid sant om nettleseren ikke verifiserer på dette tidspunktet. Det finnes to situasjoner:
A. Jeg har aldri sett dette siden nettleseren ble installert. Så feiler valideringen.
B. Hvis nettleseren har sett og verifisert i før, vil verifiseringen være vellykket.
Vanligvis vil administratoren gå til https-nettsiden til sertifikatutstederen for å kjøpe sertifikatet, og nettleseren vil verifisere det, og deretter cache alle mellomliggende sertifikater som er vellykket verifisert, noe som sparer tid i fremtiden. Når administratoren (ved en feil) konfigurerte nettsiden sin og gikk for å bla gjennom testen, ville han ikke støte på noen problemer i det hele tatt. Fordi nettleseren hans allerede gjenkjenner dette mellomliggende sertifikatet.
Mange brukere har imidlertid kanskje ikke besøkt andre korrekt konfigurerte nettsteder utstedt av dette mellomliggende sertifikatet. Derfor feiler valideringen fordi den ikke kan finne en pålitelig utsteder.
Den kan sammenlignes med utslippskontrollen fra Volkswagens dieselbiler. Alt var fint da jeg sjekket. Så snart de kommer ut, putter de gift.
REDIGERING: Hvordan fikse ...... Det er sannsynligvis å legge til SSLCertificateChainFile-innstillingen når serveren konfigureres, og bruke bundle-filen som tilbys av sertifikatutstederens nettside (filen inneholder en rekke mellomliggende sertifikater for å etablere forbindelsen mellom sertifikatet ditt og et høytillitssertifikat).
|
Publisert på 15.08.2017 21:08:39
|
|
|
