Mi a különbség a http és a https között? Az SSL titkosítási folyamat részletes magyarázata

Az internet gyors fejlődésével egyesek WeChat marketinget és nyilvános fiókok népszerűsítését szeretnék végezni , de panaszkodnak, hogy az online marketing hatástalan. Valójában az új média szakemberei számára a legjobb módja az online marketingnek a keresőmotorokon keresztüli forgalomterelés .

Ezért a keresőmotorok napjainkban az egyik legnépszerűbb online marketingeszköznek számítanak.

Ezenkívül a Google és a Baidu keresőmotorok nyilvánosan kijelentették, hogy a https szerepel a keresőmotorok rangsorolási mechanizmusában.

Különösen az e-kereskedelmi weboldalak esetében ajánlott a HTTPS titkosítási protokoll használata, amely nemcsak a rangsorolás javítását segíti, hanem a felhasználó webhelybiztonsági élményét is fokozza.

Hypertext Transfer Protocol A HTTP protokoll a webböngésző és a webszerver közötti információátvitelre szolgál A HTTP protokoll tiszta szövegben küldi el a tartalmat, és nem biztosít semmilyen adattitkosítást Ha egy támadó elfogja a webböngésző és a webszerver közötti kapcsolatot Ezért a HTTP protokoll A protokoll nem alkalmas bizonyos érzékeny információk, például hitelkártyaszám, jelszó és egyéb fizetési információk továbbítására.

A HTTP protokoll ezen hibájának kiküszöbölésére egy másik protokollt kell alkalmazni: a HTTPS biztonságos socket réteg hipertext átviteli protokollt. Az adatátvitel biztonsága érdekében a HTTPS hozzáadja az SSL protokollt a HTTP-hez, az SSL pedig tanúsítványokra támaszkodik a hitelesítés ellenőrzésére. szerver. , és titkosítja a kommunikációt a böngésző és a szerver között.

XNUMX. A HTTP és HTTPS alapfogalmai

HTTP: a legszélesebb körben használt hálózati protokoll az interneten. Ez egy kliens- és szerveroldali kérés- és válaszszabvány (TCP), amely a hipertext továbbítására szolgál a WWW szerverről a helyi böngészőbe. hatékony, ami kevesebb hálózati átvitelt eredményez.

HTTPS: Ez egy biztonságos HTTP csatorna, röviden a HTTP biztonságos változata, vagyis SSL réteg hozzáadása a HTTP-hez A HTTPS biztonsági alapja az SSL, így a titkosítás részletes tartalmához SSL szükséges.

A HTTPS protokoll fő funkciói két típusra oszthatók: az egyik az információbiztonsági csatorna létrehozása az adatátvitel biztonságának biztosítása érdekében, a másik pedig a weboldal hitelességének megerősítése.

XNUMX. Mi a különbség a HTTP és a HTTPS között?

A HTTP-protokoll által továbbított adatok titkosítatlanok, azaz egyszerű szöveges formában, ezért nagyon nem biztonságos a HTTP protokoll használata privát információk továbbítására.Annak érdekében, hogy ezek a privát adatok titkosíthatók és továbbíthatóak legyenek, a Netscape megtervezte a A HTTPS SSL (Secure Sockets Layer) protokollja a HTTP protokoll által továbbított adatok titkosítására született.

Röviden, a HTTPS protokoll az SSL+HTTP protokoll által felépített hálózati protokoll, amely titkosított átvitelt és identitás-hitelesítést tud végrehajtani, és biztonságosabb, mint a http protokoll.

A HTTPS és a HTTP közötti fő különbségek a következők:

• 1. Tanúsítvány igényléséhez a https protokollnak el kell mennie a CA-hoz.Általában kevés az ingyenes tanúsítvány, ezért bizonyos díjat kell fizetni.
• 2. A http egy hipertext átviteli protokoll, az információ továbbítása egyszerű szövegben történik, a https pedig egy biztonságos ssl-titkosított átviteli protokoll.
• 3. A http és a https teljesen más csatlakozási módot és más portot használ.Az előbbi 80, az utóbbi 443.
• 4. A http kapcsolat nagyon egyszerű és állapotmentes, a HTTPS protokoll egy SSL+HTTP protokollal felépített hálózati protokoll, amely titkosított átvitelt és identitás-hitelesítést tud végrehajtani, ami biztonságosabb, mint a http protokoll.

XNUMX. A HTTPS és SSL titkosítási folyamat részletes ismertetése

Mindannyian tudjuk, hogy a HTTPS képes titkosítani az információkat, hogy megakadályozza az érzékeny információk harmadik felek általi megszerzését, ezért sok banki webhely, e-mail és egyéb magas biztonsági szinttel rendelkező szolgáltatás fogja használni a HTTPS protokollt.

1. Az ügyfél HTTPS kérést kezdeményez

Ez nem mondható el, vagyis a felhasználó beír egy https URL-t a böngészőbe, majd csatlakozik a szerver 443-as portjához.

2. Szerver konfiguráció

A HTTPS protokollt használó szervernek rendelkeznie kell digitális tanúsítványkészlettel, amelyet saját maga készíthet, vagy alkalmazhat a szervezethez. A különbség az, hogy az Ön által kiállított tanúsítványt a kliensnek ellenőriznie kell a hozzáférés folytatásához, míg egy megbízható cég által alkalmazott tanúsítvány nem. Megjelenik egy prompt oldal.

Ez a tanúsítványkészlet valójában a nyilvános kulcs és a privát kulcs párja. Ha nem érti a nyilvános kulcsot és a privát kulcsot, elképzelheti kulcsként és zárként, de Ön az egyetlen ember a világon, aki rendelkezik ezt a kulcsot.Lezárhatod a zárat.Menj másokhoz,mások ezzel a zárral zárhatnak fontos dolgokat,majd elküldhetik neked,mert csak neked van ez a kulcs,így csak te láthatod a zárral zárt dolgokat.

3. Küldje el a tanúsítványt

Ez a tanúsítvány valójában a nyilvános kulcs, de sok információt tartalmaz, például a tanúsítvány kibocsátóját, lejárati idejét stb.

4. Ügyfélelemzési tanúsítvány

A munka ezen részét az ügyfél TLS-je végzi. Először is ellenőrzi, hogy a nyilvános kulcs érvényes-e, például a kibocsátó jogosultságot, a lejárati időt stb. Ha kivételt talál, egy figyelmeztető ablak jelenik meg, jelezve, hogy probléma van a tanúsítvánnyal.

Ha nincs probléma a tanúsítvánnyal, akkor generáljon egy véletlenszerű értéket, majd használja a tanúsítványt a véletlen érték titkosításához, ahogy fentebb említettük, zárja le a véletlenszerű értéket egy zárral, hogy ha nincs kulcs, akkor ne lássa a zárolt értékű tartalom.

5. Titkosított információ továbbítása

Ez a rész a tanúsítvánnyal titkosítva továbbítja a véletlenszerű értéket, melynek célja, hogy a szerver megkapja ezt a véletlenszerű értéket, majd ezen a véletlen értéken keresztül titkosítható és visszafejthető a kliens és a szerver közötti kommunikáció.

6. Szolgáltatási szegmens visszafejtési információi

A szerver a privát kulccsal történő visszafejtést követően megkapja a kliens által küldött véletlenszerű értéket (privát kulcsot), majd az értéken keresztül szimmetrikusan titkosítja a tartalmat, így a privát kulcs ismerete hiányában a tartalom nem érhető el, és a kliens és a szerver is ismeri a privát kulcsot, tehát amíg a titkosítási algoritmus elég erős és a privát kulcs elég összetett, addig az adatok elég biztonságosak.

7. Titkosított információ továbbítása

Az információ ezen része a szolgáltatási szegmens privát kulcsával titkosított információ, amely a kliens oldalon visszaállítható.

8. Az ügyfél visszafejtési információi

A kliens a korábban generált privát kulccsal dekódolja a szolgáltatási szegmens által küldött információkat, és így megkapja a visszafejtett tartalmat, még akkor is tehetetlen, ha a harmadik fél az egész folyamat során figyeli az adatokat.

Negyedszer, a keresőmotorok hozzáállása a HTTPS-hez

A Baidu elindított egy teljes webhelyre kiterjedő HTTPS-titkosított keresőszolgáltatást, hogy megoldja a "harmadik fél" szippantását és a felhasználók adatainak eltérítését. Valójában a Google már 2010 májusában elkezdett HTTPS-titkosított keresési szolgáltatásokat nyújtani, és HTTPS-weboldalakat feltérképezni. A probléma kapcsán a Baidu egy 5. szeptemberi közleményében kijelentette, hogy "a Baidu nem fogja aktívan feltérképezni a HTTPS-weboldalakat", míg a Google az algoritmusfrissítésben kijelentette, hogy "ugyanolyan feltételek mellett a HTTPS titkosítási technológiát használó webhelyek jobb keresési rangsort kapnak. Előny" .

Tehát ebben a környezetben a weboldal tulajdonosoknak el kellene-e fogadniuk a „kockázatos” HTTPS protokollt? És milyen hatással van a HTTPS a keresőmotorok SEO- jára?

1. A Google hozzáállása

A Google hozzáállása a HTTPS-webhelyek bevonásával kapcsolatban nem különbözik a HTTP-webhelyekétől, sőt a keresési rangsorolási algoritmusban referenciatényezőnek tekinti a „biztonságos titkosítás használatát” (HTTPS). A HTTPS-titkosítási technológiát használó webhelyek jobb eredményeket érhetnek el. Több megjelenítési lehetőség van, és a helyezés is előnyösebb, mint a hasonló oldalak HTTP-oldalai.

A Google pedig egyértelművé tette, hogy "remélik, hogy minden webmester a HTTPS protokollt tudja majd használni a HTTP helyett", ami azt mutatja, hogy eltökélt a "HTTPS mindenütt" cél elérésére.

2. Baidu hozzáállása

Korábban a Baidu technológiája viszonylag elmaradott volt, mondván, hogy „nem fogja aktívan feltérképezni a https oldalakat”, de „aggódott” amiatt is, hogy „sok https oldalt nem lehet belefoglalni”. 2014. szeptember 9-ig a Baidu a „Hogyan https-webhelyek építése a cél elérése érdekében". A „Barátság a Baidu számára" kérdéssel kapcsolatban megjelent egy cikk, amely négy javaslatot és konkrét intézkedést tartalmaz a „https-webhelyek Baidu-barát jellegének javítására”:

1. Tegyen elérhetővé http-verziókat a https-oldalak számára, amelyeket a Baidu keresőmotornak indexelnie kell.

2. A látogatót a felhasználói ügynöke azonosítja, és a Baidu duspidert egy HTTP oldalra irányítja át. Amikor egy átlagos felhasználó a Baidu keresőmotoron keresztül éri el ezt az oldalt, egy 301-es átirányítással a megfelelő HTTPS oldalra kerül átirányításra. Amint a képen látható, a felső kép a Baidu által indexelt HTTP verziót, az alsó kép pedig azt a HTTPS verziót mutatja, amely automatikusan átirányítja a felhasználót a kattintás után.

3. A http verzió nem csak a kezdőlapra készül, a többi fontos oldalt is http verzióval kell elkészíteni, és egymáshoz kell kapcsolni, ezt ne tedd: a kezdőlapon lévő http-oldal linkje továbbra is a https oldalra kapcsolódik , ami miatt a Baiduspider nem tudja folytatni a feltérképezést—— Olyan helyzettel találkoztunk, hogy a teljes webhelyhez csak egy kezdőlapot tudunk felvenni.

4. Aldoméneket használhatsz olyan tartalmak tárolására, amelyek nem igényelnek titkosítást, például híreket. Például az Alipay webhelyén a titkosított tartalom HTTPS-en keresztül tárolódik, míg a Baiduspider által közvetlenül feltérképezhető tartalom aldoméneken található.

Az alábbi linken található Computer Science House tesztje szerint a HTTP-vel 114 ezredmásodpercig tart, a HTTPS-sel 436 ezredmásodpercig, az ssl részhez pedig 322 ezredmásodpercig tart, beleértve a hálózati késleltetést és a többletterhelést is. magának az ssl-nek a titkosításáról és dekódolásáról (a szerver a kliens információi szerint határozza meg, hogy kell-e új mesterkulcsot generálni; a szerver válaszol a mesterkulcsra és a mesterkulccsal hitelesített üzenetet küld vissza a kliensnek; a szerver digitális aláírást és nyilvános kulcsot kér az ügyféltől).

XNUMX. Mennyi erőforrást fogyaszt a HTTPS, mint a HTTP?

A HTTPS valójában egy SSL/TLS-re épülő HTTP protokoll. Ezért Chen Weiliang úgy véli, hogy a HTTPS és a HTTP közötti különbség főként az SSL/TLS által felhasznált szervererőforrások mennyiségétől függ.

A HTTP a TCP háromirányú kézfogását használja a kapcsolat létrehozásához, és az ügyfélnek és a szervernek 3 csomagot kell cserélnie;

A HTTPS-nek a három TCP csomagon kívül még 9 csomagot kell hozzáadnia az ssl handshake-hez, így összesen 12 csomag van.

Miután létrejött egy SSL-kapcsolat, a következő titkosítási módszer egy szimmetrikus titkosítási módszerré válik, például a 3DES-sé, amely alacsonyabb CPU-terheléssel jár. Az SSL-kapcsolat létrehozásához használt aszimmetrikus titkosítási módszerhez képest a szimmetrikus titkosítás CPU-terhelése elhanyagolható. Ez azonban egy problémához vezet: az SSL-munkamenet gyakori újraépítése végzetes hatással lehet a szerver teljesítményére. Bár a HTTPS keepalive engedélyezése enyhítheti az egyetlen kapcsolat teljesítményproblémáit, nagyméretű, nagyszámú egyidejű felhasználóval rendelkező webhelyek esetén elengedhetetlen egy dedikált, terheléselosztáson alapuló SSL-lezáró proxy. A webszolgáltatás az SSL-lezáró proxy után kerül elhelyezésre. Az SSL-lezáró proxy lehet hardveralapú, például az F5, vagy szoftveralapú , például a Wikipédia által használt Nginx.

Mennyivel több szervererőforrást fognak felhasználni a HTTPS bevezetése után? 2010 januárjában a Gmail teljes HTTPS-re váltott. Az elő-end SSL-feldolgozó gép CPU-terhelése legfeljebb 1%-kal nőtt, a kapcsolatonkénti memóriafogyasztás kevesebb mint 20 KB volt, a hálózati forgalom pedig kevesebb mint 2%-kal nőtt. Mivel a Gmail valószínűleg N szervert használ az elosztott feldolgozáshoz, a CPU-terhelési adatok nem túl jelentősek. A kapcsolatonkénti memóriafogyasztás és a hálózati forgalmi adatok értelmesebbek. A cikk azt is felsorolja, hogy egyetlen mag körülbelül 1500 kézfogást képes feldolgozni másodpercenként (1024 bites RSA esetén), ami egy nagyon jelentős adat.

XNUMX. A HTTPS előnyei

Pontosan azért, mert a HTTPS nagyon biztonságos, a támadók nem találnak kiindulási pontot. A webmesterek szemszögéből a HTTPS előnyei a következők:

1. SEO szempontok

A Google 2014 augusztusában módosította keresőmotor-algoritmusát, és azt mondta, hogy "a HTTPS-sel titkosított webhely magasabb rangot kap a keresési eredményekben, mint egy ezzel egyenértékű HTTP-oldal".

2. Biztonság

Bár a HTTPS nem teljesen biztonságos, a gyökértanúsítványokat és a titkosítási algoritmusokat uraló szervezetek is végrehajthatnak „man-in-the-middle” támadásokat, de a HTTPS továbbra is a legbiztonságosabb megoldás a jelenlegi architektúra mellett, a következő előnyökkel:

(1) Használja a HTTPS protokollt a felhasználók és szerverek hitelesítésére annak biztosítására, hogy az adatok a megfelelő kliensnek és szervernek kerüljenek elküldésre;

(2) A HTTPS protokoll az SSL+HTTP protokollal felépített, titkosított átvitelt és identitás-hitelesítést végrehajtó hálózati protokoll, amely biztonságosabb, mint a http protokoll, amely megakadályozza az adatok ellopását és megváltoztatását az átviteli folyamat során, és biztosítja a az adatok integritását.

(3) A HTTPS a legbiztonságosabb megoldás a jelenlegi architektúra mellett, bár nem teljesen biztonságos, de nagymértékben megnöveli a köztes támadások költségeit.

XNUMX. A HTTPS hátrányai

Noha a HTTPS-nek vannak nagy előnyei, vannak még hiányosságai. Konkrétan a következő két pont van:

1. SEO szempontok

Az ACM CoNEXT adatai szerint a HTTPS protokoll használata közel 50%-kal meghosszabbítja az oldal betöltési idejét és 10-20%-kal növeli az energiafogyasztást, emellett a HTTPS protokoll hatással lesz a gyorsítótárra is, növeli az adattömeg- és energiafogyasztást. , sőt a meglévő biztonsági intézkedések is érintettek lesznek, és ennek megfelelően.

Ezenkívül a HTTPS protokoll titkosítási hatóköre viszonylag korlátozott, és csekély hatása van a hackertámadásokra, a szolgáltatásmegtagadási támadásokra és a szerver-eltérítésre.

A legfontosabb az, hogy az SSL-tanúsítványok hitellánc-rendszere nem biztonságos, különösen akkor, ha egyes országok képesek ellenőrizni a CA gyökértanúsítványát, lehetséges a középső támadás.

2. Gazdasági szempontok

(1) Az SSL-tanúsítványokhoz pénz kell. Minél erősebb a tanúsítvány, annál magasabbak a költségek. A személyes webhelyek ingyenes SSL-tanúsítványokat használhatnak.

(2) Az SSL-tanúsítványokat általában IP-hez kell kötni, és több domain név nem köthető ugyanahhoz az IP-címhez. Az IPv4-erőforrások ezt a fogyasztást nem tudják támogatni (az SSL-nek vannak olyan kiterjesztései, amelyek részben megoldják ezt a problémát, de ez problémás és böngészőket igényel, működés Rendszertámogatás, a Windows XP nem támogatja ezt a bővítményt, az XP telepített bázisát tekintve ez a funkció szinte használhatatlan).

(3) A HTTPS-kapcsolat gyorsítótárazása nem olyan hatékony, mint a HTTP, és a nagy forgalmú webhelyek nem használják, hacsak nem szükséges, és a forgalmi költség túl magas.

(4) A HTTPS-kapcsolat szerveroldali erőforrás-felhasználása sokkal magasabb, és a kicsit több látogatóval rendelkező webhelyek támogatása nagyobb költséget igényel. Ha az összes HTTPS-t használjuk, akkor a VPS átlagos költsége azon a feltételezésen alapul, hogy a számítási erőforrások nagy része tétlen fel fog menni.

(5) A HTTPS protokoll kézfogási fázisa időigényes és negatív hatással van a weboldal megfelelő sebességére, ha nem szükséges, akkor nincs ok a felhasználói élmény feláldozására.

XNUMX. A webhelyet HTTPS-sel kell titkosítani?

Bár a Google és a Baidu „másképp nézi a HTTPS-t”, ez nem jelenti azt, hogy a webmestereknek át kell alakítaniuk a webhely protokollját HTTPS-re!

Mindenekelőtt beszéljünk a Google-ról, bár a Google folyamatosan hangsúlyozza, hogy "a HTTPS titkosítási technológiát használó webhelyek jobb helyezéseket érhetnek el", nem zárható ki, hogy ez egy " hátsó szándékú " lépés.

Külföldi elemzők erre a kérdésre válaszolva azt mondták: nem biztos, hogy a Google ezt a lépést tette meg (az algoritmus frissítése, hogy a HTTPS titkosítási technológiát használja-e referenciatényezőként a keresőmotorok rangsorolásánál) nem a felhasználói keresési élmény és az internet javítása miatt. A biztonsági kérdés csupán a „Prism Gate" botrány „veszteségének" helyreállítása. Ez egy tipikus önérdekű lépés az „egó feláldozása" zászlaja alatt, a „Security Impact Ranking" zászlajának magasra tartása és a „HTTPS" skandálása. mindenhol" ” szlogennel, majd könnyedén engedje, hogy a webmesterek többsége készségesen csatlakozzon a HTTPS protokoll táborához.

Ha webhelye az e-kereskedelmi / mikrovállalkozási platformhoz, pénzügyhöz, közösségi hálózatokhoz vagy más területhez tartozik, akkor a legjobb a HTTPS protokollt használni; ha blogoldalról, promóciós weboldalról, titkosított információkat tartalmazó weboldalról vagy hírportálról van szó, akkor ingyenes SSL-tanúsítványt használhat.

XNUMX. Hogyan készít egy webmester HTTPS-webhelyet?

A HTTPS oldalak felépítésénél meg kell említenünk az SSL protokollt. Az SSL a Netscape által elfogadott első hálózati biztonsági protokoll, amely a Transmission Communication Protocol (TCP/IP) protokollon implementált biztonsági protokoll. , SSL széles körben támogatja különböző típusú hálózatok, miközben három alapvető biztonsági szolgáltatást nyújtanak, mind nyilvános kulcsú technológiát használnak.

A HTTPS oldalak felépítésénél meg kell említenünk az SSL protokollt. Az SSL a Netscape által elfogadott első hálózati biztonsági protokoll, amely a Transmission Communication Protocol (TCP/IP) protokollon implementált biztonsági protokoll. , SSL széles körben támogatja különböző típusú hálózatok, miközben három alapvető biztonsági szolgáltatást nyújtanak, mind nyilvános kulcsú technológiát használnak.

1. Az SSL szerepe

(1) A felhasználók és szerverek hitelesítése annak biztosítása érdekében, hogy az adatok a megfelelő klienshez és szerverhez kerüljenek elküldésre;

(2) Titkosítsa az adatokat, hogy megakadályozza az adatok félúton történő ellopását;

(3) Fenntartja az adatok sértetlenségét, és gondoskodjon arról, hogy az adatok ne változzanak a továbbítási folyamat során.

Az SSL-tanúsítvány egy digitális fájl, amely az SSL-kommunikációban mindkét fél személyazonosságát ellenőrzi. Általában szervertanúsítványra és kliens tanúsítványra oszlik. Az SSL-tanúsítvány általában a szervertanúsítványra vonatkozik. Az SSL-tanúsítvány megbízható digitális hitelesítésszolgáltató CA (például VeriSign, GlobalSign, WoSign stb.) által kibocsátott, a szerver azonosságának ellenőrzése után kiadott, szerver hitelesítési és adatátviteli titkosítási funkciókkal, kiterjesztett érvényesítésű (EV) SSL tanúsítványra osztva, Szervezeti érvényesítési (OV) SSL-tanúsítvány és tartománynév-ellenőrzési típusú (DV) SSL-tanúsítvány.

2. 3 fő lépés az SSL-tanúsítvány igényléséhez

Az SSL-tanúsítvány igénylésének három fő lépése van:

(1), készítsen CSR-fájlt

Az úgynevezett CSR a kérelmező által előállított Certificate Secure Request tanúsítványkérő fájl, melynek gyártási folyamata során a rendszer két kulcsot generál, az egyik a nyilvános kulcs, amely a CSR fájl, a másik pedig a privát kulcs. amely a szerveren van tárolva.

CSR-fájlok készítéséhez a pályázók a WEB-SZERVER-dokumentumokra, az általános APACHE-re stb. hivatkozhatnak, az OPENSSL parancssor segítségével hozhatók létre KEY+CSR2-fájlok, a Tomcat, a JBoss, a Resin stb. használhatja a KEYTOOL-ot a JKS- és CSR-fájlok létrehozásához, az IIS pedig egyet a varázsló függőben lévő kérésein és egy CSR-fájlon keresztül.

(2), CA-tanúsítvány

Küldje el a CSR-t a CA-nak, és a CA általában két hitelesítési módszerrel rendelkezik:

① Domain név hitelesítés: Általában az adminisztrátor postafiókját hitelesítik, ez a hitelesítési mód gyors, de a kiállított tanúsítvány nem tartalmazza a cég nevét.

② Vállalkozási okirat igazolása: A vállalkozás iparűzési engedélye szükséges, ami általában 3-5 munkanapot vesz igénybe.

Vannak olyan tanúsítványok is, amelyeknek a fenti két módszert egyszerre kell hitelesíteniük, amit EV-tanúsítványnak hívnak, ez a tanúsítvány az IE2 feletti böngészők címsorát zöldre válthatja, így a hitelesítés is a legszigorúbb.

(3) bekezdése szerint a tanúsítvány telepítése

Miután megkapta a tanúsítványt a CA-tól, telepítheti a tanúsítványt a szerveren. Általában az APACHE fájl közvetlenül a KEY+CER fájlba másolja, majd módosítja a HTTPD.CONF fájlt; TOMCAT stb., importálni kell a tanúsítványt A CA által kiadott CER-fájlt a JKS-fájlba. , másolja a kiszolgálóra, majd módosítsa a SERVER.XML-t; az IIS-nek fel kell dolgoznia a függőben lévő kérelmet, és importálnia kell a CER-fájlt.

XNUMX. Ingyenes SSL-tanúsítvány ajánlása

Az SSL-tanúsítványok használata nemcsak az információbiztonságot fokozza, hanem növeli a felhasználók bizalmát a weboldalakban. Sok weboldal-tulajdonos azonban a weboldal-építési költségek miatt habozik. Az ingyenes szolgáltatások mindig időtlen piacot jelentenek az interneten; ahogy vannak ingyenes tárhelylehetőségek, úgy vannak ingyenes SSL-tanúsítványok is. Korábban arról számoltak be, hogy a Mozilla, a Cisco, az Akamai, az IdenTrust, az EFF és a Michigani Egyetem kutatói elindítják a Let's Encrypt CA projektet, amelynek célja, hogy idén nyártól ingyenes SSL-tanúsítványokat és tanúsítványkezelési szolgáltatásokat biztosítson a weboldalaknak (megjegyzés: a fejlettebb és összetettebb tanúsítványokért fizetni kell). A projekt leegyszerűsíti a tanúsítványok telepítését is, a telepítési időt mindössze 20-30 másodpercre csökkentve.

Gyakran a nagy és közepes méretű webhelyek igényelnek összetett tanúsítványokat, és a kis webhelyek, például a személyes blogok először kipróbálhatják az ingyenes SSL-tanúsítványokat.

Az alábbiakban Chen Weiliang blogbejegyzése további ingyenes SSL-tanúsítványokat mutat be, mint például a Cloudflare SSL és a NameCheap.

1. CloudFlare SSL

A CloudFlare egy CDN-szolgáltatásokat nyújtó webhely az Egyesült Államokban. Saját CDN-szerver csomópontokkal rendelkezik a világ minden táján. Számos nagyvállalat vagy webhely itthon és külföldön használja a CloudFlare CDN-szolgáltatásait. Természetesen a hazai webmesterek által leggyakrabban használt a CloudFlare ingyenes CDN-je. Az is nagyon jó. A CloudFlare által biztosított ingyenes SSL-tanúsítvány UniversalSSL, azaz univerzális SSL. A felhasználók az SSL-tanúsítványt anélkül használhatják, hogy tanúsítványt kérnének és konfigurálnának egy tanúsító hatóságtól. A CloudFlare SSL titkosítást biztosít minden felhasználó (beleértve az ingyenes felhasználókat is), webes felület A tanúsítvány beállítása 5 percen belül megtörténik, az automatikus telepítés 24 órán belül megtörténik, elliptikus görbe digitális aláírási algoritmuson (ECDSA) alapuló TLS titkosítási szolgáltatást biztosítva a weboldal forgalmához.

2. NévOlcsó

A NameCheap 2000-ben alapított vezető ICANN-akkreditált domain név regisztrációs és webtárhelyszolgáltató cég, amely ingyenes DNS-feloldást, URL-továbbítást (elrejthet az eredeti URL-címen, támogatja a 301-es átirányítást) és egyéb szolgáltatásokat, ezen felül a NameCheap egy Több éves SSL tanúsítvány nélküli szolgáltatás.

3. Encrypt

A Let's Encrypt egy népszerű ingyenes SSL-tanúsítvány-kibocsátási projekt a közelmúltban.A Let's Encrypt az ISRG által biztosított ingyenes és ingyenes közjóléti projekt, amely automatikusan állít ki tanúsítványokat, de a tanúsítvány csak 90 napig érvényes.Személyes vagy ideiglenes használatra alkalmas, és már nem kell elviselnie azt a felszólítást, hogy az önaláírt tanúsítványt a böngésző nem bízza meg.

Tulajdonképpen Chen Weiliang blogja is tervezi a Let's Encrypt használatát a közelmúltban ^_^

Az ingyenes Let's Encrypt SSL tanúsítvány igénylésének útmutatójáért kérjük, tekintse meg ezt a cikket: „ Hogyan igényeljünk Let's Encrypt tanúsítványt ”.