Kako riješiti pogreške TLS certifikata i HTTPS stranice koje se ne učitavaju

Kada se sigurna stranica prestane učitavati, preglednik prikaže čudno upozorenje o certifikatu i lokot nestane, normalno je da se malo zanesete panikom. Pogreške TLS certifikata i HTTPS stranice koje se ne učitavaju Mogu uništiti povjerenje korisnika, naglo smanjiti prodaju i, usput rečeno, oštetiti SEO ako se brzo ne poduzmu mjere.

Dobra vijest je da većina ovih grešaka ima objašnjenje i rješenje. Mnogi problemi nastaju zbog jednostavne pogrešne konfiguracije, isteklih certifikata, miješanog sadržaja ili DNS pogrešaka.a ne sofisticiranim napadima. U ovom ćete vodiču korak po korak vidjeti kako prepoznati najčešće uzroke, kako ispraviti svaku vrstu pogreške (i s korisničke i s poslužiteljske strane) i što učiniti kako biste ih spriječili u budućnosti.

Što je TLS/SSL certifikat i zašto se HTTPS veza prekida?

Prije nego što se nešto dirate, važno je razumjeti što se događa ispod površine. TLS/SSL certifikat je digitalna datoteka koja identificira vašu web-stranicu i šifrira podatke između preglednika i poslužitelja.To vam omogućuje prebacivanje s HTTP-a na HTTPS i prikaz poznatog lokota u adresnoj traci.

Taj certifikat izdaje priznato tijelo za certificiranje (CA) i uključuje naziv domene, datumi važenja i javni ključPrati ga lanac međucertifikata koji proširuju povjerenje sve do korijenskog CA. Ako je bilo što u tom lancu ili u konfiguraciji netočno, preglednik prekida povjerenje i prikazuje poruku o pogrešci.

Ovih dana ljudi gotovo nikada ne govore o "čistom" SSL-u. Moderni preglednici koriste TLS (Transport Layer Security), evoluciju SSL-aIako još uvijek uobičajeno koristimo SSL/TLS, princip je isti: pregovara se o šifriranoj vezi, certifikat se validira i, ako sve prođe dobro, korisnik pregledava internet sa zaštićenim podacima.

Kad stvari ne idu baš dobro, događa se sljedeće Preglednik ne može provjeriti je li poslužitelj onaj za koga se predstavlja ili ispunjava li veza minimalne sigurnosne zahtjeveTamo ćete pronaći pogreške poput ERR_SSL_PROTOCOL_ERROR, nevažeće certifikate, upozorenja o "neprivatnoj vezi" i druge lijepe stvari koje bi uplašile svakog prosječnog posjetitelja.

Najčešći uzroci pogrešaka TLS i HTTPS certifikata koji se ne uspijevaju učitati

Ne pojavljuju se sva sigurnosna upozorenja iz istog razloga. Iza pogreške TLS certifikata mogu biti problemi s konfiguracijom poslužitelja, kvarovi certifikata, DNS pogreške ili čak lokalne korisničke postavke. (datum, antivirus, vatrozid itd.). Razumijevanje uzroka sprječava nagađanje.

Prva velika razlika je između pogreške na strani poslužitelja (web stranica) i pogreške na strani klijenta (korisnički uređaj)Kao administratori, možemo djelovati samo na strani poslužitelja, ali korisno je poznavati obje strane kako bismo ispravno dijagnosticirali problem.

Među najčešćim uzrocima na strani poslužitelja su: Istekli certifikati, neusklađene domene, nepotpuni međunizovi, zastarjeli TLS protokoli ili loše konfigurirana HTTP/HTTPS preusmjeravanjaMješoviti sadržaj je također čest: stranica se učitava putem HTTPS-a, ali neki resursi se i dalje zahtijevaju putem HTTP-a.

Iz perspektive korisnika, mnogi strahovi dolaze od Netočan datum i vrijeme sustava, oštećena predmemorija preglednika, antivirusni programi ili vatrozidovi koji presreću vezu, neispravan DNS ili manipulirane datoteke hostovaSve to može pokrenuti upozorenja poput ERR_SSL_PROTOCOL_ERROR čak i ako je poslužitelj savršeno konfiguriran.

Tipične SSL/TLS pogreške i što one zapravo znače

Preglednici prikazuju mnogo različitih poruka, ali gotovo sve se mogu grupirati u nekoliko kategorija. Svaki kod pogreške ukazuje na određenu vrstu problema s certifikatom ili vezomZnati ih čitati je pola rješenja.

Jedan od najpoznatijih je ERR_SSL_PROTOCOL_ERRORTo ukazuje na to da preglednik nije mogao dovršiti TLS protokol s tim poslužiteljem: to može biti zbog isteklog certifikata, nepodržanog protokola, miješanog sadržaja, pogrešaka u lancu povjerenja ili čak oštećene datoteke hosts koja vas vodi na drugo odredište od onog koje očekujete.

Još jedan klasik je ERR_CERT_COMMON_NAME_INVALIDOvo upozorenje se pojavljuje kada naziv domene u certifikatu ne odgovara domeni kojoj pokušavate pristupiti. To je ozbiljno upozorenje jer To bi mogao biti simptom napada tipa "čovjek u sredini" ili loše konfiguracije poslužitelja. (na primjer, posluživanje istog certifikata za više domena bez odgovarajućih SAN-ova).

Također je uobičajeno vidjeti NET :: ERR_CERT_AUTHORITY_INVALIDTo ukazuje na to da certifikat nije izdao CA kojem preglednik vjeruje. To može biti zbog samopotpisanih certifikata, internih certifikata ili zato što antivirusni program ili proxy ubrizgava vlastiti certifikat, a preglednik ga ne prepoznaje kao pouzdanog.

Usko povezano je Neto :: ERR_CERT_DATE_INVALIDOvo ukazuje na problem s datumom: ili je certifikat istekao ili vrijeme na korisnikovom računalu ne odgovara razdoblju važenja. TLS certifikati su datirani; ako ste izvan tog razdoblja, preglednik pretpostavlja da mu se ne može vjerovati.

Postoje i druge, manje ugodne poruke, kao što su ERR_SSL_VERSION_OR_CIPHER_MISMATCHTo se obično pojavljuje kada poslužitelj podržava samo starije protokole ili šifre koje moderni preglednici više ne prihvaćaju. U praksi to znači da Konfiguracija servera je zastarjela i potrebno ju je ažurirati.

U nekim slučajevima nailazimo ERR_SSL_WEAK_EPHEMERAL_DH_KEYTo ukazuje na to da poslužitelj koristi nedovoljno slabe privremene Diffie-Hellmanove ključeve. Korisnik malo toga može učiniti po tom pitanju. Odgovornost je na administratoru poslužitelja, koji mora modernizirati kriptografsku konfiguraciju..

Konačno, iako se ne radi o pogrešci certifikata per se, poruka ERR_TOO_MANY_REDIRECTS To se događa kada pravila preusmjeravanja između HTTP i HTTPS ili između verzija s www i bez www stvaraju beskonačnu petlju. Preglednik se prebacuje s jednog URL-a na drugi dok ne odustane, a stranica se nikada ne učitava.

Pogreške mješovitog sadržaja i HTTPS stranice koje "nisu u potpunosti sigurne"

Jedan od najozbiljnijih problema su pogreške mješovitog sadržajaDo toga dolazi kada se glavna stranica učitava putem HTTPS-a, ali Neki interni resursi (slike, skripte, stilski listovi, iframeovi...) još se uvijek pozivaju putem HTTP-aRezultat: preglednik upozorava da stranica nije u potpunosti sigurna ili izravno blokira te resurse.

Ovaj scenarij je vrlo čest nakon migracije web-mjesta s HTTP-a na HTTPS bez pravilne provjere internih ruta. Nekoliko slika ili skripta s apsolutnim URL-om u HTTP-u dovoljni su za pokretanje upozorenja.U produkcijskim okruženjima, neki preglednici čak blokiraju nesigurne skripte ili iframeove, što narušava kritične funkcionalnosti.

Pronalaženje ovih resursa stvar je pregleda koda ili korištenja alata za reviziju. Rješenje uključuje promjenu URL-ova u HTTPS, korištenje putanja relativnih prema shemi ili ažuriranje predložaka i dodataka koji generiraju zastarjele poveznice.U mnogim CMS-ovima, dobar alat za pretraživanje i zamjenu u bazi podataka (korišten pažljivo) dovoljan je za ispravljanje stotina poveznica odjednom.

Ne govorimo samo o slikama ili CSS-u. Vanjske skripte, biblioteke trećih strana i API pozivi također moraju putovati putem HTTPS-aAko se vaša stranica učitava putem HTTPS-a, ali uključuje API pozive koji koriste HTTP, neki će preglednici blokirati zahtjeve, prekinuti tijek prijave ili spriječiti učitavanje određenih modula.

U konkretnom slučaju modernih aplikacija, također je potrebno pregledati OAuth URI-ji za preusmjeravanje (npr. s Googlea) koji upućuju na localhost ili HTTPOva kombinacija može uzrokovati čudne pogreške, neočekivana upozorenja o certifikatima (kao što je samopotpisani certifikat od "localhost") i, povrh svega, utjecati samo na određenog korisnika ili okruženje.

Uobičajeni problemi s instalacijom i valjanošću certifikata

Osim miješanog sadržaja, velik dio sukoba proizlazi iz načina na koji je certifikat instaliran ili obnovljen. Loše instaliran ili nevažeći SSL/TLS certifikat obično je posljedica neusklađenih domena, nepotpunih međulanaca ili poslužitelja koji još uvijek poslužuju stari certifikat..

Ako certifikat ne odgovara domeni (na primjer, pokriva samo mydomain.com, a vi pristupate www.mydomain.com), preglednik će označiti vezu kao nesigurnu. Prilikom kupnje ili generiranja certifikata morate osigurati da uključite sve potrebne varijacije (sa i bez www, poddomena itd.).ili koristite zamjenske SAN-ove kada je to prikladno.

Još jedna klasična greška je zaboravi srednji lanacMnogi CA-ovi isporučuju više datoteka; ako poslužitelj poslužuje samo primarni certifikat bez lanca do korijenskog CA-a, neki preglednici neće moći uspostaviti povjerenje. Rezultat: Korisnik vidi naizgled valjan certifikat, ali preglednik ga ne prepoznaje kao takvog..

I tijekom renovacija ima iznenađenja. To je relativno uobičajeno. Obnovite certifikat kod davatelja usluga, ali nemojte ažurirati vezu na poslužitelju ili platformi za hosting.Nadzorna ploča pokazuje da je izdan novi certifikat, ali web stranica i dalje poslužuje stari, istekli certifikat. Dok se ponovno ne sinkronizira (ili se ponovno ne izvrši vezanje), posjetitelji će i dalje vidjeti upozorenja.

U upravljanim platformama poput Azure App Servicea ili Vercela, u obzir dolaze i drugi čimbenici. dozvole za spremište ključeva ili veze između certifikata i prilagođenih domenaAko servis koji upravlja certifikatima nema dovoljna dopuštenja za Key Vault ili ako automatska sinkronizacija nije pokrenuta, aplikacija će nastaviti koristiti stari certifikat.

Također moramo biti oprezni kombinacija SNI veza i SSL veza temeljenih na IP-uU nekim okruženjima, kada se oboje koristi istovremeno, klijenti koji ne podržavaju SNI uvijek primaju certifikat vezan uz njihovu IP adresu, čak i ako pristupaju web-mjestu putem domene koja bi trebala koristiti drugu. To može rezultirati prikazom netočnog certifikata, naizgled "nasumično", ovisno o tome tko se povezuje.

HTTP/HTTPS preusmjeravanja, domene i DNS: izvori nevidljivih pogrešaka

Čak i s savršenim certifikatom, vaša web stranica se možda neće učitati putem HTTPS-a ako postoje problemi s preusmjeravanja, domena ili DNSTi slojevi, koje obično dotaknemo jednom i zaboravimo, neiscrpan su izvor suptilnih pogrešaka.

Da bi stranica uvijek izgledala sigurno, normalno je Forsirajte HTTPS pomoću pravila preusmjeravanja (npr. u .htaccess, Nginx, kontrolnoj ploči hostinga ili obrnutom proxyju)Ako su ova pravila neispravno postavljena, možete stvoriti petlje između http:// i https:// ili između www i ne-www. Tipičan rezultat: ERR_TOO_MANY_REDIRECTS ili stranica koja se jednostavno ne prikazuje.

Također morate paziti na to kako je domena konfigurirana kod DNS pružatelja usluga. Prilikom usmjeravanja domene na web aplikaciju ili uslugu u oblaku, morate ispravno koristiti A, CNAME i TXT zapise.Korištenje i A zapisa i CNAME zapisa za isti host, zaboravljanje TXT-a za provjeru ili neažuriranje IP adrese prilikom promjene poslužitelja generirat će pogreške u rješavanju problema (DNS_PROBE_FINISHED_NXDOMAIN i druge).

Osim toga, DNS se ne ažurira odmahSvaki zapis ima TTL (Time To Live) vrijednost, koja pokazuje koliko dugo ga resolveri mogu pohraniti u predmemoriju. Ako ste nedavno promijenili pružatelje hostinga ili IP adrese, normalno je da neki korisnici i dalje vide staru stranicu ili pogrešku 404 nekoliko sati. Alati poput WhatsMyDNS-a mogu pomoći u provjeri ispravnog napredovanja propagacije.

Drugi put problem leži u korisnikovom pregledniku ili sustavu. Lokalni DNS i predmemorija preglednika mogu zadržati stare adrese.Obrišite predmemoriju, ispraznite DNS (na primjer, s ipconfig / flushdns (na Windowsima) ili ponovno pokretanje usmjerivača obično je dovoljno kako bi se osiguralo da se domena ispravno razrješava na pravi poslužitelj.

Ne smijemo zaboraviti ni arhivu. Domaćini operativnog sustava. Prije nego što je DNS postojao, sve se rješavalo tamo, a on se i danas koristi za fiksna mapiranja u lokalnim mrežama. Zlonamjerni softver, alati za otklanjanje pogrešaka ili zastarjele konfiguracije mogu ga izmijeniti i preusmjeriti vas na neočekivane IP adrese ili lažne certifikate.Vraćanje datoteke u zadano stanje obično eliminira mnoge neobjašnjive greške ERR_SSL_PROTOCOL_ERROR jednim potezom.

Posebni scenariji: oblaci, paneli i ograničenja platforme

Ako radite s upravljanim platformama (Azure, Vercel, cPanel itd.), postoje pogreške koje su uvjetovane samom infrastrukturom. Način na koji povezujete certifikate s aplikacijama, ograničenja kupnje i vrsta plana utječu na to kako i kada možete koristiti TLS..

U Azure App Serviceu, na primjer, nećete moći kupiti ili koristiti certifikate ako Plan je na besplatnoj ili dijeljenoj tarifi koja ne podržava TLS.Također nećete moći kupiti više certifikata nego što vaša vrsta pretplate dopušta. Ako je certifikat označen kao potencijalno lažan, ostat će u pregledu dok davatelj certifikata ne provjeri domenu i ne ukine blokadu.

Također je relativno uobičajeno da Isti certifikat pokušava se povezati s više aplikacija s istom IP adresom koristeći veze temeljene na IP-u.Ako VIP već koristi taj certifikat, portal može odbiti dodavanje drugog povezivanja i prikazati poruku o pogrešci u kojoj se navodi da "drugi VIP već koristi taj certifikat". Rješenje je ukloniti prethodno povezivanje ili koristiti SNI povezivanja kad god je to moguće.

Što se tiče prilagođenih domena kupljenih putem ovih platformi, važno je napomenuti da Oslanjaju se na vanjske registratore (kao što je GoDaddy) i Azure DNS ili druge pružatelje usluga DNS hostinga.To znači da možete imati ograničenja kupnje, pravila automatskog obnavljanja i odvojene troškove za registraciju i DNS.

Ako se domena greškom izbriše, obično Postoji kratko vrijeme (nekoliko dana) u kojem se može vratiti bez dodatnih troškova.Nakon tog razdoblja, morat ćete kontaktirati podršku davatelja usluga ili registrara kako biste provjerili je li još uvijek dostupno i kako ga vratiti. U međuvremenu, povezani certifikati bit će nedostupni.

konačno, Format certifikata je važanMnoge platforme zahtijevaju .pfx datoteke s lozinkom i punim nizom. Ako vaš CA pruža certifikate u .pem ili .key formatu, morat ćete ih pretvoriti (na primjer, pomoću OpenSSL-a) i uključiti privatni ključ i sve međupodatke ispravnim redoslijedom prije nego što ih možete prenijeti.

Kako ispraviti pogreške SSL veze sa strane korisnika

Ako ste korisnik i naiđete na stranicu koja se ne učitava putem HTTPS-a, nećete je uvijek moći popraviti (ako je problem s poslužiteljem, malo toga možete učiniti). Postoji nekoliko brzih koraka koje vrijedi isprobati prije odustajanja.Jer često problem leži u vašem vlastitom uređaju.

Prvo što treba učiniti je pregledati datum i vrijeme vašeg sustavaSamo nekoliko minuta odgode dovoljno je da se neki naizgled valjani certifikati smatraju isteklima ili "još nevažećima". Omogućavanje automatske sinkronizacije datuma i vremena (na Windowsima, macOS-u, Androidu ili iOS-u) obično rješava dobar broj pogrešaka SSL veze odjednom.

Zatim je vrijeme za čišćenje kuće: obriši kolačiće i predmemoriju preglednikaU Chromeu, Firefoxu, Safariju i drugima možete izbrisati pohranjene kolačiće i privremene datoteke iz izbornika postavki. To prisiljava preglednik da ponovno zatraži certifikate i sprječava ga da nastavi prenositi stara stanja ili zastarjela preusmjeravanja.

Na stolnim računalima, to je dobra ideja izbrišite SSL "slate" ili predmemorirane certifikate u sustavuU sustavu Windows to se radi putem Internet Options, kartice Content, pomoću gumba Clear SSL State. U sustavu macOS možete koristiti Keychain Access za pronalaženje certifikata povezanih s određenom domenom i njihovo ručno brisanje.

Ako stvari ostanu iste, sljedeći osumnjičenik je sigurnosni softverNeki antivirusni programi i vatrozidovi presreću HTTPS veze radi analize, ubrizgavajući vlastiti certifikat. Ako nešto pođe po zlu tijekom ovog procesa, pojavit će se pogreške nevažećeg autoriteta ili protokola. Privremeno onemogućavanje antivirusnog programa ili vatrozida (samo za testiranje) može potvrditi jesu li oni krivci.

Još jedna brza provjera je Pokušajte koristiti drugi preglednik ili uređaj, a ako je moguće, čak i drugu mrežu (mobilne podatke umjesto Wi-Fi-ja).Ako radi na drugim preglednicima i uređajima, problem je u vašem računalu. Ako ne radi nigdje, problem je najvjerojatnije u poslužitelju ili domeni.

Najbolje prakse za sprječavanje pogrešaka TLS certifikata

Osim gašenja požara, ono što je zaista zanimljivo jest da se ove pogreške gotovo nikada ne događaju. Sprječavanje problema s TLS certifikatima uključuje ažuriranje i dobro praćenje certifikata, poslužitelja i DNS-a..

Prva točka je očita, ali se lako zaboravlja: Obnovite certifikate prije isteka i, ako je moguće, automatizirajte procesS Let's Encryptom i mnogim modernim CA-ima, jednostavno je postaviti automatske obnove, tako da ih ne morate pamtiti svakih nekoliko mjeseci. Unatoč tome, dobra je ideja pratiti datume isteka i primati obavijesti.

Također je ključno Održavajte server i sigurnosne protokole ažurnimaSSLv3, TLS 1.0 i drugi zastarjeli protokoli moraju se onemogućiti, a umjesto njih treba koristiti TLS 1.2 i 1.3, zajedno s modernim paketima šifriranja i dovoljno jakim ključevima. Vodiči poput Mozilla SSL konfiguracije mogu se koristiti kao referenca za konfiguriranje poslužitelja s prihvatljivom razinom sigurnosti.

Ništa manje važno nije Povremeno provjeravajte pravila preusmjeravanja između HTTP-a i HTTPS-a te između varijanti domenaNaizgled nevina promjena (novo pravilo u .htaccess, proxy CDN, umetnuti WAF) može uvesti petlje ili poslati promet na nesigurnu verziju. Pregled preusmjeravanja i izvođenje testova punog opterećenja nakon svake promjene dobra je praksa.

Druga ključna mjera je Provjerite web-mješoviti sadržajTo se posebno odnosi na migracije na HTTPS ili kada se instaliraju novi dodaci, teme ili vanjske integracije. Jedan HTTP resurs može oštetiti percipiranu sigurnost cijele web stranice i dovesti do selektivnog blokiranja sadržaja.

Konačno, ne smijemo zaboraviti na alati za provjeru certifikataOnline usluge poput SSL Labsa ili vlastiti dijagnostički alati dobavljača omogućuju vam analizu lanca certifikata, aktivnih protokola, kompatibilnosti preglednika i potencijalnih ranjivosti. Integriranje ovih pregleda u rutinske zadatke održavanja pomaže u otkrivanju pogrešaka prije nego što ih kupci primijete.

Kad se sve sabere, jasno je da Pogreške TLS certifikata i HTTPS stranice koje se ne učitavaju rijetko su posljedica "crne magije"Gotovo uvijek postoji zaboravljeni datum isteka, nepotpuna lozinka, pogrešno konfiguriran DNS ili jednostavno vremenska razlika na korisnikovom uređaju. Rješavanjem najčešćih uzroka, automatizacijom obnavljanja, upravljanjem preusmjeravanjima i korištenjem dobrih praksi konfiguracije možete značajno smanjiti ove sigurnosne alarme i ponuditi svojim posjetiteljima glatko, sigurno i besprijekorno iskustvo pregledavanja svaki put kada vide zeleni lokot.

Povezani članak:

Filtrirajte kritične događaje, upozorenja i pogreške pomoću Get-WinEventa

Isaac

Strastveni pisac o svijetu bajtova i tehnologije općenito. Volim dijeliti svoje znanje pisanjem, a to je ono što ću učiniti na ovom blogu, pokazati vam sve najzanimljivije stvari o gadgetima, softveru, hardveru, tehnološkim trendovima i još mnogo toga. Moj cilj je pomoći vam da se snađete u digitalnom svijetu na jednostavan i zabavan način.