TLS-sertifikaadi vigade ja HTTPS-lehtede laadimise katkemise lahendamine

Kui turvaline leht laadimise lõpetab, brauser kuvab sertifikaadi kohta kummalise hoiatuse ja tabalukk kaob, on normaalne väike paanika. TLS-sertifikaadi vead ja HTTPS-lehed, mille laadimine ebaõnnestub Kui kiiresti meetmeid ei võeta, võivad need hävitada kasutajate usalduse, järsult müüki vähendada ja muuseas kahjustada SEO-d.

Hea uudis on see, et enamikul neist vigadest on seletus ja lahendus. Paljud probleemid tulenevad lihtsast valest konfiguratsioonist, aegunud sertifikaatidest, segatud sisust või DNS-vigadest.ja mitte keerukate rünnakute vastu. Selles juhendis näete samm-sammult, kuidas tuvastada kõige levinumaid põhjuseid, kuidas parandada iga tüüpi viga (nii kasutaja kui ka serveri poolelt) ja mida teha nende vältimiseks tulevikus.

Mis on TLS/SSL-sertifikaat ja miks HTTPS-ühendus katkeb?

Enne millegi kallale asumist on oluline aru saada, mis toimub all. TLS/SSL-sertifikaat on digitaalne fail, mis tuvastab teie saidi ja krüpteerib andmeid brauseri ja serveri vahel.See võimaldab teil lülituda HTTP-lt HTTPS-ile ja näha aadressiribal kuulsat tabalukku.

Selle sertifikaadi on välja andnud tunnustatud sertifitseerimisasutus (CA) ja see sisaldab järgmist: domeeninimi, kehtivuskuupäevad ja avalik võtiSellega kaasneb vahesertifikaatide ahel, mis laiendab usaldust kuni juursertifitseerimisasutuseni. Kui miski selles ahelas või konfiguratsioonis on vale, rikub brauser usalduse ja kuvab veateate.

Tänapäeval ei räägita peaaegu kunagi "puhast" SSL-ist. Tänapäevased brauserid kasutavad TLS-i (transpordikihi turvalisus), mis on SSL-i edasiarendus.Kuigi me ikka veel kasutame SSL/TLS-i, on põhimõte sama: lepitakse kokku krüptitud ühendus, valideeritakse sertifikaat ja kui kõik läheb hästi, sirvib kasutaja oma andmed kaitstuna.

Kui asjad ei lähe nii hästi, siis juhtubki nii, et Brauser ei saa kinnitada, et server on see, kelleks ta väidab end olevat, või et ühendus vastab minimaalsetele turvanõuetele.Sealt leiad selliseid vigu nagu ERR_SSL_PROTOCOL_ERROR, kehtetud sertifikaadid, "mitteprivaatse ühenduse" hoiatused ja muud toredat, mis peletaks iga keskmise külastaja eemale.

TLS-i ja HTTPS-i sertifikaatide laadimise ebaõnnestumise kõige sagedasemad põhjused

Kõik turvahoiatused ei ilmu samal põhjusel. TLS-sertifikaadi vea taga võivad olla serveri konfiguratsiooniprobleemid, sertifikaadi tõrked, DNS-vead või isegi kohalikud kasutajaseaded. (kuupäev, viirusetõrje, tulemüür jne). Põhjuste mõistmine säästab teid oletustest.

Esimene oluline erinevus seisneb serveripoolsed vead (veebisait) ja kliendipoolsed vead (kasutaja seade)Administraatoritena saame tegutseda ainult serveri poolel, aga probleemi õigeks diagnoosimiseks on kasulik tunda mõlemat poolt.

Kõige tüüpilisemate serveripoolsete põhjuste hulka kuuluvad: Aegunud sertifikaadid, mittevastavad domeenid, mittetäielikud vahetekstid, aegunud TLS-protokollid või halvasti konfigureeritud HTTP/HTTPS-i ümbersuunamisedSamuti on levinud segatud sisu: leht laadib HTTPS-i kaudu, kuid mõningaid ressursse taotletakse ikkagi HTTP kaudu.

Kasutaja vaatenurgast tulenevad paljud hirmud sellest, Vale süsteemi kuupäev ja kellaaeg, rikutud brauseri vahemälu, ühendust katkestav viirusetõrje või tulemüürid, vigane DNS või manipuleeritud hostfailidKõik see võib käivitada hoiatusi, näiteks ERR_SSL_PROTOCOL_ERROR, isegi kui server on ideaalselt konfigureeritud.

Tüüpilised SSL/TLS vead ja mida need tegelikult tähendavad

Brauserid kuvavad palju erinevaid sõnumeid, kuid peaaegu kõik need saab jagada mõnda kategooriasse. Iga veakood viitab konkreetsele sertifikaadi või ühenduse probleemile.Nende lugemise oskus on pool lahendusest.

Üks tuntumaid on ERR_SSL_PROTOCOL_ERRORSee näitab, et brauser ei suutnud selle serveriga TLS-protokolli lõpule viia: selle põhjuseks võib olla aegunud sertifikaat, toetamata protokoll, segatud sisu, usaldusahela vead või isegi rikutud hosts-fail, mis viib teid oodatust erinevasse sihtkohta.

Teine klassika on ERR_CERT_COMMON_NAME_INVALIDSee hoiatus kuvatakse siis, kui sertifikaadis olev domeeninimi ei vasta domeenile, millele proovite juurde pääseda. See on tõsine hoiatus, sest See võib olla sümptomiks niinimetatud „vahepealse mehe rünnakust“ kui ka kohutavast serveri konfiguratsioonist. (näiteks sama sertifikaadi pakkumine mitme domeeni jaoks ilma sobivate SAN-ideta).

Samuti on tavaline näha NET :: ERR_CERT_AUTHORITY_INVALIDSee näitab, et sertifikaati ei väljastanud brauseri poolt usaldusväärne sertifitseerimisasutus. Selle põhjuseks võivad olla iseallkirjastatud sertifikaadid, sisemised sertifikaadid või see, et viirusetõrje või puhverserver sisestab oma sertifikaadi ilma, et brauser seda usaldusväärseks peaks.

Lähedalt seotud on Net::ERR_CERT_DATE_INVALIDSee viitab kuupäevaprobleemile: kas sertifikaat on aegunud või kasutaja arvuti aeg ei vasta kehtivusajale. TLS-sertifikaadid on dateeritud; kui olete väljaspool seda perioodi, eeldab brauser, et neid ei saa usaldada.

On ka teisi, vähem meeldivaid sõnumeid, näiteks ERR_SSL_VERSION_OR_CIPHER_MISMATCHSee ilmneb tavaliselt siis, kui server toetab ainult vanemaid protokolle või šifrikomplekte, mida tänapäeva brauserid enam ei aktsepteeri. Praktikas tähendab see, et Serveri konfiguratsioon on aegunud ja vajab uuendamist.

Mõnel juhul puutume kokku ERR_SSL_WEAK_EPHEMERAL_DH_KEYSee näitab, et server kasutab ebapiisavalt nõrku ajutisi Diffie-Hellmani võtmeid. Kasutaja ei saa sellega eriti midagi teha. Vastutus lasub serveri administraatoril, kes peab krüptograafilise konfiguratsiooni kaasajastama..

Lõpuks, kuigi see pole iseenesest sertifikaadi viga, siis teade ERR_TOO_MANY_REDIRECTS See juhtub siis, kui ümbersuunamisreeglid HTTP ja HTTPS või www ja mitte-www versioonide vahel loovad lõputu tsükli. Brauser põrkab ühelt URL-ilt teisele, kuni annab alla, ja leht ei laadi kunagi.

Segase sisu vead ja „mitte täielikult turvalised” HTTPS-saidid

Üks kõige ohtlikumaid probleeme on segatud sisu veadNeed juhtuvad siis, kui põhileht laaditakse HTTPS-i kaudu, aga Mõned sisemised ressursid (pildid, skriptid, stiililehed, iframe'id...) kutsutakse endiselt HTTP kaudu.Tulemus: brauser hoiatab, et sait pole täiesti turvaline või blokeerib need ressursid otse.

See stsenaarium on väga levinud pärast saidi migreerimist HTTP-lt HTTPS-ile ilma sisemisi marsruute korralikult kontrollimata. Paar pilti või absoluutse URL-iga skript HTTP-s on hoiatuste käivitamiseks piisav.Tootmiskeskkondades blokeerivad mõned brauserid isegi ohtlikke skripte või iframe'e, mis rikub kriitilisi funktsioone.

Nende ressursside leidmine on koodi kontrollimise või auditeerimisvahendite kasutamise küsimus. Lahendus hõlmab URL-ide muutmist HTTPS-iks, skeemiga seotud teede kasutamist või aegunud linke genereerivate mallide ja pistikprogrammide värskendamist.Paljudes sisuhaldussüsteemides piisab andmebaasis olevast heast otsingu-asendustööriistast (mida kasutatakse hoolikalt), et parandada korraga sadu linke.

Me ei räägi ainult piltidest või CSS-ist. Välised skriptid, kolmandate osapoolte teegid ja API-kõned peavad samuti liikuma HTTPS-i kaudu.Kui teie leht laadib HTTPS-i kaudu, aga sisaldab HTTP-protokolli kasutavaid API-kõnesid, blokeerivad mõned brauserid päringud, katkestavad sisselogimisvoo või takistavad teatud moodulite laadimist.

Kaasaegsete rakenduste puhul on samuti vaja üle vaadata OAuthi ümbersuunamise URI-d (nt Google'ist), mis osutavad localhostile oa HTTP kauduSee kombinatsioon võib põhjustada kummalisi vigu, ootamatuid sertifikaadihoiatusi (näiteks "localhosti" iseallkirjastatud sertifikaat) ja lisaks kõigele muule mõjutada ainult konkreetset kasutajat või keskkonda.

Levinud installimis- ja sertifikaadi kehtivusprobleemid

Lisaks segasele sisule tuleneb suur osa konfliktist sellest, kuidas sertifikaat installiti või uuendati. Halvasti installitud või kehtetu SSL/TLS-sertifikaadi põhjuseks on tavaliselt sobimatud domeenid, mittetäielikud vaheahelad või serverid, mis ikka veel vana sertifikaati pakuvad..

Kui sertifikaat ei vasta domeenile (näiteks katab see ainult domeeni mydomain.com, aga teie külastate domeeni www.mydomain.com), märgib brauser ühenduse ebaturvaliseks. Sertifikaadi ostmisel või genereerimisel peate veenduma, et lisate kõik vajalikud variatsioonid (www-ga ja ilma, alamdomeenid jne).või kasutage vajadusel metamärkidega SAN-e.

Teine klassikaline viga on unusta keskmine kettPaljud sertifitseerimisasutused edastavad mitu faili; kui server edastab ainult peamist sertifikaati ilma juursertifitseerijani ulatuva ahelata, ei suuda mõned brauserid usaldust luua. Tulemus: Kasutaja näeb pealtnäha kehtivat sertifikaati, kuid brauser seda sellisena ei tunne..

Renoveerimise ajal tuleb ette ka üllatusi. See on suhteliselt tavaline. Uuenda sertifikaati pakkuja juures, aga ära uuenda linki serveris ega hostimisplatvormil.Armatuurlaud näitab, et uus sertifikaat on väljastatud, kuid veebisait teenindab endiselt vana, aegunud sertifikaati. Kuni see pole uuesti sünkroonitud (või sidumine pole uuesti tehtud), näevad külastajad jätkuvalt hoiatusi.

Hallatavatel platvormidel nagu Azure App Service või Vercel tulevad mängu ka muud tegurid. võtmehoidla õigused või sertifikaatide ja kohandatud domeenide vahelised seosedKui sertifikaate haldaval teenusel pole võtmehoidlas piisavalt õigusi või kui automaatset sünkroonimist pole käivitatud, jätkab rakendus vana sertifikaadi kasutamist.

Samuti peame olema valvsad SNI-linkide ja IP-põhiste SSL-linkide kombinatsioonMõnes keskkonnas, kui mõlemat kasutatakse samaaegselt, saavad SNI-d mittetoetavad kliendid alati oma IP-aadressiga seotud sertifikaadi, isegi kui nad pääsevad saidile juurde domeeni kaudu, mis peaks kasutama teist domeeni. See võib kaasa tuua vale sertifikaadi esitamise, mis näib olevat "juhuslik", olenevalt sellest, kes ühenduse loob.

HTTP/HTTPS ümbersuunamised, domeenid ja DNS: nähtamatute vigade allikad

Isegi ideaalse sertifikaadi korral ei pruugi teie veebisait HTTPS-i kaudu laadida, kui sellega on probleeme ümbersuunamised, domeen või DNSNeed kihid, mida me tavaliselt üks kord puudutame ja siis unustame, on ammendamatu peente vigade allikas.

Selleks, et sait alati turvalisena näiks, on tavaline, et Sunni HTTPS ümbersuunamisreeglite abil (nt .htaccess-failis, Nginx-is, hostimise juhtpaneelil või pöördproksi abil)Kui need reeglid on valesti seadistatud, võite luua tsükleid http:// ja https:// või www ja mitte-www vahel. Tüüpiline tulemus on ERR_TOO_MANY_REDIRECTS või leht, mida lihtsalt ei kuvata.

Samuti peate hoolitsema selle eest, kuidas domeen on DNS-pakkujas konfigureeritud. Domeeni veebirakendusele või pilveteenusele suunamisel peate A-, CNAME- ja TXT-kirjeid õigesti kasutama.Sama hosti puhul nii A-kirje kui ka CNAME-kirje kasutamine, kinnitus-TXT unustamine või IP-aadressi mittevärskendamine serveri vahetamisel tekitab lahendusvigu (DNS_PROBE_FINISHED_NXDOMAIN ja muud).

Lisaks DNS ei uuene koheseltIgal kirjel on TTL (Time To Live) väärtus, mis näitab, kui kaua resolverid seda vahemällu salvestada saavad. Kui olete hiljuti majutusteenuse pakkujat või IP-aadressi vahetanud, on normaalne, et mõned kasutajad näevad vana saiti või 404 viga mitu tundi. Tööriistad nagu WhatsMyDNS aitavad kontrollida, kas levitamine edeneb õigesti.

Teinekord peitub probleem kasutaja brauseris või süsteemis. Kohalik DNS ja brauseri vahemälu saavad vanu aadresse säilitada.Tühjendage vahemälu, loputage DNS-i (näiteks käsuga ipconfig / flushdns (Windowsis) või ruuteri taaskäivitamisest piisab tavaliselt, et domeen õigele serverile õigesti suunataks.

Samuti ei tohi unustada arhiivi. hosts operatsioonisüsteemist. Enne DNS-i olemasolu lahendati kõik seal ja seda kasutatakse tänapäevalgi kohalike võrkude fikseeritud vastenduste jaoks. Pahavara, veatuvastustööriistad või aegunud konfiguratsioonid võivad seda muuta ja teid ootamatutele IP-aadressidele või võltsitud sertifikaatidele suunata.Faili vaikesätetele taastamine kõrvaldab tavaliselt paljud seletamatud ERR_SSL_PROTOCOL_ERROR vead ühe hoobiga.

Eristsenaariumid: pilved, paneelid ja platvormi piirangud

Hallatud platvormidega (Azure, Vercel, cPanel jne) töötades esineb vigu, mis on tingitud infrastruktuurist endast. Sertifikaatide rakendustega seostamise viis, ostulimiidid ja paketi tüüp mõjutavad kõik seda, kuidas ja millal saate TLS-i kasutada..

Näiteks Azure'i rakenduste teenuses ei saa te sertifikaate osta ega kasutada, kui Pakett on tasuta või jagatud hinnaga, mis ei toeta TLS-i.Samuti ei saa te osta rohkem sertifikaate, kui teie tellimuse tüüp lubab. Kui sertifikaat märgistatakse potentsiaalselt petturlikuks, jääb see läbivaatamisele, kuni sertifikaadi pakkuja domeeni kontrollib ja blokeerimise tühistab.

Samuti on suhteliselt tavaline, et Sama sertifikaat proovib IP-põhiste linkide abil luua ühenduse mitme sama IP-aadressiga rakendusega.Kui VIP seda sertifikaati juba kasutab, võib portaal keelduda teise sidumise lisamisest ja kuvada veateate, mis ütleb: "teine ​​VIP juba kasutab seda sertifikaati". Lahenduseks on eelmise sidumise eemaldamine või võimaluse korral SNI-sidumiste kasutamine.

Nende platvormide kaudu ostetud kohandatud domeenide puhul on oluline märkida, et Nad toetuvad DNS-majutuse osas välistele registripidajatele (nt GoDaddy) ja Azure DNS-ile või teistele pakkujatele.See tähendab, et teil võivad olla ostulimiidid, automaatse uuendamise reeglid ning eraldi kulud registreerimise ja DNS-i eest.

Kui domeen kustutatakse kogemata, siis tavaliselt Selle saab lisakuludeta taastada lühikese aja jooksul (mõni päev).Pärast seda perioodi peate võtma ühendust teenusepakkuja või registripidaja toega, et näha, kas see on endiselt saadaval ja kuidas seda taastada. Seni on seotud sertifikaadid ebakindlas seisukorras.

Lõpuks Sertifikaatide vorming on olulinePaljud platvormid nõuavad parooli ja täieliku stringiga .pfx-faile. Kui teie sertifitseerimisasutus pakub sertifikaate .pem- või .key-vormingus, peate need enne üleslaadimist teisendama (näiteks OpenSSL-i abil) ja lisama privaatvõtme ning kõik vaheandmed õiges järjekorras.

Kuidas parandada SSL-ühenduse vigu kasutaja poolelt

Kui oled kasutaja ja satud lehte, mis HTTPS-i kaudu ei laadi, ei saa sa seda alati parandada (kui probleem on serveris, siis pole sul suurt midagi teha). Aga Enne allaandmist on mitu kiiret sammu, mida tasub proovida.Sest tihtipeale on probleem sinu enda seadmes.

Esimene asi, mida teha, on ülevaatamine teie süsteemi kuupäev ja kellaaegJuba mõneminutilisest viivitusest piisab, et mõned pealtnäha kehtivad sertifikaadid loetaks aegunuks või "veel mittekehtivaks". Automaatse kuupäeva ja kellaaja sünkroonimise lubamine (Windowsis, macOS-is, Androidis või iOS-is) lahendab tavaliselt korraga hulga SSL-ühenduse vigu.

Järgmisena on aeg maja koristada: tühjenda brauseri küpsised ja vahemäluChrome'is, Firefoxis, Safaris ja teistes brauserites saate salvestatud küpsiseid ja ajutisi faile seadete menüüst kustutada. See sunnib brauserit sertifikaate uuesti küsima ja takistab vanade olekute või aegunud ümbersuunamiste ülekandmist.

Lauaarvutites on see hea mõte kustutage süsteemist SSL-i „tahvli” või vahemällu salvestatud sertifikaadidWindowsis saab seda teha Interneti-suvandite (Internet Options) vahekaardi Sisu (Consume) kaudu, kasutades nuppu Tühjenda SSL-i olek (Clear SSL State). macOS-is saab konkreetse domeeniga seotud sertifikaatide leidmiseks ja käsitsi kustutamiseks kasutada funktsiooni Keychain Access.

Kui asjad jäävad samaks, on järgmine kahtlusalune turvatarkvaraMõned viirusetõrjeprogrammid ja tulemüürid pealt kuulavad HTTPS-ühendusi analüüsimiseks, sisestades oma sertifikaadi. Kui selle protsessi käigus midagi valesti läheb, ilmuvad sobimatu volituse või protokolli vead. Viirusetõrje või tulemüüri ajutine keelamine (lihtsalt testimiseks) aitab kinnitada, kas need on süüdlased.

Veel üks kiire kontroll on Proovige kasutada teist brauserit või seadet ja võimalusel isegi teist võrku (mobiilne andmeside WiFi asemel).Kui see töötab teistes brauserites ja seadmetes, on probleem teie arvutis. Kui see ebaõnnestub kõikjal, on probleem tõenäoliselt serveris või domeenis.

Parimad tavad TLS-sertifikaadivigade vältimiseks

Lisaks tulekahjude kustutamisele on tõeliselt huvitav see, et neid vigu peaaegu kunagi ei esine. TLS-sertifikaadiprobleemide ennetamine hõlmab sertifikaatide, serverite ja DNS-i ajakohasena hoidmist ja head jälgimist..

Esimene punkt on ilmselge, aga kergesti unustatav: Uuenda sertifikaate enne nende aegumist ja võimalusel automatiseeri protsessLet's Encrypti ja paljude tänapäevaste CA-dega on automaatsete uuenduste seadistamine lihtne, nii et te ei pea iga paari kuu tagant meeles pidama. Sellegipoolest on hea mõte jälgida aegumiskuupäevi ja saada teavitusi.

See on samuti ülioluline Hoidke serverit ja turvaprotokolle ajakohasenaSSLv3, TLS 1.0 ja muud aegunud protokollid tuleb keelata ning nende asemel tuleks kasutada TLS 1.2 ja 1.3 koos kaasaegsete šifrikomplektide ja piisavalt tugevate võtmetega. Serveri vastuvõetava turvatasemega konfigureerimiseks saab abiks olla juhendid, näiteks Mozilla SSL-i konfiguratsioon.

Vähem tähtis pole Kontrollige perioodiliselt ümbersuunamisreegleid HTTP ja HTTPS vahel ning domeenivariantide vahelPealtnäha süütu muudatus (uus reegel .htaccess-failis, puhverserveri CDN, vahepealne WAF) võib tekitada tsükleid või suunata liikluse ebaturvalisse versiooni. Hea tava on pärast iga muudatust ümbersuunamiste ülevaatamine ja täiskoormuse testide tegemine.

Teine oluline meede on Auditeeri saiti segasisu suhtesSee kehtib eriti pärast HTTPS-ile üleminekut või uute pluginate, teemade või väliste integratsioonide installimist. Üks HTTP-ressurss võib kahjustada kogu veebisaidi tajutavat turvalisust ja viia valikulise sisu blokeerimiseni.

Lõpuks ei tohi me unustada, sertifikaatide kontrollimise tööriistadVeebiteenused nagu SSL Labs või müüjate enda diagnostikavahendid võimaldavad teil analüüsida sertifikaatide ahelat, aktiivseid protokolle, brauserite ühilduvust ja võimalikke haavatavusi. Nende ülevaadete integreerimine rutiinsetesse hooldustöödesse aitab vigu tuvastada enne, kui kliendid neid märkavad.

Kõike kokku pannes saab selgeks, et TLS-sertifikaadi vead ja HTTPS-lehtede laadimise ebaõnnestumised on harva tingitud "mustast maagiast".Peaaegu alati on tegemist unustatud aegumiskuupäeva, mittetäieliku parooli, valesti konfigureeritud DNS-iga või lihtsalt kellaaja erinevusega kasutaja seadmes. Kõige levinumate põhjuste lahendamise, uuendamiste automatiseerimise, ümbersuunamiste haldamise ja heade konfigureerimistavade kasutamise abil saate neid turvahoiatusi oluliselt vähendada ja pakkuda külastajatele sujuvat, turvalist ja tõrgeteta sirvimiskogemust iga kord, kui nad rohelist tabalukku näevad.

Seotud artikkel:

Kriitiliste sündmuste, hoiatuste ja vigade filtreerimine funktsiooniga Get-WinEvent

Isaac

Kirglik kirjanik baitide maailmast ja üldse tehnoloogiast. Mulle meeldib jagada oma teadmisi kirjutamise kaudu ja just seda ma selles ajaveebis teengi, näitan teile kõike kõige huvitavamat vidinate, tarkvara, riistvara, tehnoloogiliste suundumuste ja muu kohta. Minu eesmärk on aidata teil digimaailmas lihtsal ja meelelahutuslikul viisil navigeerida.