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

Posljednje ažuriranje: 13/05/2026
Autor: Isaac
  • Greške TLS certifikata obično su uzrokovane istekom, neusklađenim domenima, nepotpunim nizovima znakova ili zastarjelim protokolima.
  • Mnogi kvarovi HTTPS veze također potiču s korisničkog uređaja: netačan datum, oštećena keš memorija ili sigurnosni softver.
  • Pravilna konfiguracija preusmjeravanja, DNS-a i sadržaja bez HTTP-a sprječava petlje, upozorenja o nesigurnim stranicama i probleme s učitavanjem.
  • Automatizacija obnavljanja i periodična revizija certifikata i servera minimizira sigurnosna upozorenja u pregledniku.

Greš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 katanac nestane, normalno je da se malo zanesete panikom. Greš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 preduzmu 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 grešaka.a ne sofisticiranim napadima. U ovom vodiču ćete korak po korak vidjeti kako identificirati najčešće uzroke, kako ispraviti svaku vrstu greške (i sa strane korisnika i sa strane servera) i šta učiniti da ih spriječite u budućnosti.

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

Prije nego što se bilo šta dirate, važno je razumjeti šta se dešava ispod površine. TLS/SSL certifikat je digitalna datoteka koja identificira vašu web stranicu i šifrira podatke između preglednika i servera.Ovo vam omogućava da pređete sa HTTP na HTTPS i vidite poznati katanac u adresnoj traci.

Taj certifikat izdaje priznato certifikacijsko tijelo (CA) i uključuje naziv domene, datumi važenja i javni ključPrati ga lanac posrednih certifikata koji proširuju povjerenje sve do korijenskog CA. Ako je bilo šta u tom lancu ili u konfiguraciji neispravno, preglednik prekida povjerenje i prikazuje poruku o grešci.

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

Kada stvari ne idu baš dobro, dešava se sljedeće Preglednik ne može provjeriti da li je server onaj za koga se predstavlja ili da li veza ispunjava minimalne sigurnosne zahtjeve.Tamo ćete pronaći greš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 grešaka TLS i HTTPS certifikata koji se ne mogu učitati

Ne pojavljuju se sva sigurnosna upozorenja iz istog razloga. Iza greške TLS certifikata mogu biti problemi s konfiguracijom servera, kvarovi certifikata, DNS greške ili čak lokalne korisničke postavke. (datum, antivirus, zaštitni zid, itd.). Razumijevanje uzroka vas štedi nagađanja.

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

Među najčešćim uzrocima na strani servera 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 uobičajen: stranica se učitava putem HTTPS-a, ali se neki resursi i dalje zahtijevaju putem HTTP-a.

Iz perspektive korisnika, mnogi strahovi dolaze od Netačan datum i vrijeme sistema, oštećena keš memorija preglednika, antivirusni programi ili zaštitni zidovi koji presreću vezu, neispravan DNS ili manipulisane host datotekeSve ovo može izazvati upozorenja poput ERR_SSL_PROTOCOL_ERROR čak i ako je server savršeno konfigurisan.

Tipične SSL/TLS greške i šta one zapravo znače

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

Jedan od najpoznatijih je ERR_SSL_PROTOCOL_ERROROvo ukazuje na to da preglednik nije mogao dovršiti TLS protokol s tim serverom: to može biti zbog isteklog certifikata, nepodržanog protokola, mješovitog sadržaja, grešaka u lancu povjerenja ili čak oštećene hosts datoteke koja vas vodi na drugu destinaciju od one koju 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 Ovo bi mogao biti simptom napada tipa "čovjek u sredini" ili loše konfiguracije servera. (na primjer, pružanje istog certifikata za više domena bez odgovarajućih SAN-ova).

  Razlike između TCP-a i UDP-a: Potpuni vodič za mrežne protokole

Također je uobičajeno vidjeti NET :: ERR_CERT_AUTHORITY_INVALIDOvo 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 računaru korisnika ne odgovara periodu važenja. TLS certifikati su datirani; ako ste izvan tog perioda, preglednik pretpostavlja da mu se ne može vjerovati.

Postoje i druge, manje ugodne poruke, kao što su ERR_SSL_VERSION_OR_CIPHER_MISMATCHOvo se obično pojavljuje kada server podržava samo starije protokole ili šifre koje moderni preglednici više ne prihvataju. 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_KEYOvo ukazuje na to da server koristi nedovoljno slabe privremene Diffie-Hellman ključeve. Korisnik malo toga može učiniti po tom pitanju. Odgovornost leži na administratoru servera, koji mora modernizirati kriptografsku konfiguraciju..

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

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

Jedan od najozbiljnijih problema su greške mješovitog sadržajaOvo se dešava kada se glavna stranica učitava putem HTTPS-a, ali Neki interni resursi (slike, skripte, stilski listovi, iframeovi...) se i dalje pozivaju putem HTTP-aRezultat: preglednik upozorava da stranica nije u potpunosti sigurna ili direktno blokira te resurse.

Ovaj scenario je vrlo čest nakon migracije web-stranice s HTTP 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 je stvar pregleda koda ili korištenja alata za reviziju. Rješenje uključuje promjenu URL-ova u HTTPS, korištenje putanja relativnih u odnosu na shemu ili ažuriranje predložaka i dodataka koji generiraju zastarjele linkove.U mnogim CMS-ovima, dobar alat za pretragu i zamjenu u bazi podataka (korišten pažljivo) dovoljan je za ispravljanje stotina linkova odjednom.

Ne pričamo samo o slikama ili CSS-u. Vanjski skriptovi, 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 preglednici će blokirati zahtjeve, prekinuti tok prijave ili spriječiti učitavanje određenih modula.

U konkretnom slučaju modernih aplikacija, potrebno je preispitati i OAuth URI-ji za preusmjeravanje (npr. od Googlea) koji pokazuju na localhost ili HTTPOva kombinacija može uzrokovati čudne greš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

Pored miješanog sadržaja, veliki 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 servera 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 kupovine ili generiranja certifikata, morate osigurati da uključite sve potrebne varijacije (sa i bez www, poddomena, itd.).ili koristite džoker SAN-ove kada je to prikladno.

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

I tokom renoviranja se dešavaju iznenađenja. To je relativno uobičajeno. Obnovite certifikat kod provajdera, ali nemojte ažurirati link na serveru ili platformi za hosting.Kontrolna ploča pokazuje da je izdat novi certifikat, ali web stranica i dalje koristi stari, istekli certifikat. Posjetioci će i dalje vidjeti upozorenja dok se ponovo ne sinhronizuje (ili se ne ponovo izvrši povezivanje).

Na upravljanim platformama poput Azure App Servicea ili Vercela, u obzir dolaze i drugi faktori. dozvole za skladište ključeva ili veze između certifikata i prilagođenih domenaAko servis koji upravlja certifikatima nema dovoljne dozvole za Key Vault ili ako automatska sinhronizacija nije pokrenuta, aplikacija će nastaviti koristiti stari certifikat.

  Spor VPN: Pravi uzroci i kako vratiti brzinu

Također moramo biti oprezni kombinacija SNI linkova i SSL linkova zasnovanih na IP-uU nekim okruženjima, kada se oba koriste istovremeno, klijenti koji ne podržavaju SNI uvijek primaju certifikat vezan za svoju IP adresu, čak i ako pristupaju stranici putem domene koja bi trebala koristiti drugu. To može rezultirati prikazom netačnog certifikata, naizgled "nasumično", ovisno o tome ko se povezuje.

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

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

Da bi stranica uvijek izgledala sigurno, normalno je da Forsirajte HTTPS koristeći pravila preusmjeravanja (npr. u .htaccess, Nginx, kontrolnoj ploči hostinga ili obrnutom proxyju)Ako su ova pravila nepravilno postavljena, možete kreirati 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 voditi računa o tome kako je domena konfigurirana kod DNS provajdera. 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 verifikacijske TXT datoteke ili neažuriranje IP adrese prilikom promjene servera generirat će greške u rješavanju problema (DNS_PROBE_FINISHED_NXDOMAIN i druge).

Takođe, DNS se ne ažurira odmahSvaki zapis ima TTL (Time To Live - vrijeme trajanja), koja pokazuje koliko dugo ga resolveri mogu keširati. Ako ste nedavno promijenili pružatelje hostinga ili IP adresu, normalno je da neki korisnici i dalje vide staru stranicu ili grešku 404 nekoliko sati. Alati poput WhatsMyDNS-a mogu pomoći u provjeri da li propagacija ispravno napreduje.

U drugim slučajevima, problem leži u korisnikovom pregledniku ili sistemu. Lokalni DNS i keš memorija preglednika mogu zadržati stare adrese.Obrišite keš memoriju, ispraznite DNS (na primjer, sa ipconfig / flushdns (na Windowsu) ili ponovno pokretanje rutera je obično dovoljno da se osigura da se domena ispravno razrješava na pravi server.

Ne smijemo zaboraviti ni arhivu. Domaćini operativnog sistema. 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 greš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 odjednom.

Posebni scenariji: oblaci, paneli i ograničenja platforme

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

Na primjer, u Azure App Serviceu 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 dozvoljava. Ako je certifikat označen kao potencijalno lažan, ostat će na pregledu dok dobavljač certifikata ne verificira 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 zasnovane na IP-u.Ako VIP već koristi taj certifikat, portal može odbiti dodavanje drugog povezivanja i prikazati poruku o greš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 Oni se oslanjaju na eksterne registratore (kao što je GoDaddy) i Azure DNS ili druge provajdere za DNS hosting.To znači da možete imati ograničenja kupovine, pravila automatskog obnavljanja i odvojene troškove za registraciju i DNS.

Ako se domena greškom obriše, obično Postoji kratak vremenski okvir (nekoliko dana) u kojem se može povratiti bez dodatnih troškova.Nakon tog perioda, morat ćete kontaktirati podršku provajdera ili registrara kako biste provjerili da li je još uvijek dostupno i kako ga vratiti. U međuvremenu, povezani certifikati će biti nedostupni.

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

Kako popraviti greške SSL veze sa strane korisnika

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

  Kako promijeniti naziv grupe u Windowsu i izbjeći mrežne konflikte

Prva stvar koju treba uraditi je pregled datum i vrijeme vašeg sistemaSamo nekoliko minuta kašnjenja je dovoljno da se neki naizgled važeći certifikati smatraju isteklim ili "još nevažećim". Omogućavanje automatske sinhronizacije datuma i vremena (na Windowsu, macOS-u, Androidu ili iOS-u) obično rješava dobar broj grešaka SSL veze odjednom.

Zatim, vrijeme je za čišćenje kuće: obrišite kolačiće i keš pretraživačaU Chromeu, Firefoxu, Safariju i drugim pretraživačima možete izbrisati pohranjene kolačiće i privremene datoteke iz menija postavki. Ovo prisiljava preglednik da ponovo zatraži certifikate i sprječava ga da nastavi prenositi stara stanja ili zastarjela preusmjeravanja.

Na desktop računarima, to je dobra ideja obrišite SSL "slate" ili keširane certifikate u sistemuNa Windowsu se to radi iz Internet opcija, kartica Sadržaj, pomoću dugmeta Obriši SSL stanje. Na macOS-u možete koristiti Keychain Access da biste pronašli certifikate povezane s određenom domenom i ručno ih izbrisali.

Ako stvari ostanu iste, sljedeći osumnjičeni je sigurnosni softverNeki antivirusni programi i zaštitni zidovi presreću HTTPS veze radi analize, ubrizgavajući vlastiti certifikat. Ako nešto pođe po zlu tokom ovog procesa, pojavit će se greške nevažećeg autoriteta ili protokola. Privremeno onemogućavanje antivirusa ili zaštitnog zida (samo radi testiranja) može potvrditi da li su 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čunaru. Ako ne radi nigdje, problem je najvjerovatnije u serveru ili domeni.

Najbolje prakse za sprečavanje grešaka TLS certifikata

Osim gašenja požara, ono što je zaista zanimljivo jeste da se ove greške gotovo nikada ne dešavaju. Sprečavanje problema sa TLS certifikatima uključuje ažuriranje i dobro praćenje certifikata, servera i DNS-a..

Prva tačka je očigledna, ali se lako zaboravlja: Obnovite certifikate prije isteka i, ako je moguće, automatizirajte procesUz Let's Encrypt i mnoge moderne CA, lako je postaviti automatska obnavljanja, tako da ne morate pamtiti svakih nekoliko mjeseci. Uprkos tome, dobra je ideja pratiti datume isteka i primati obavještenja.

To je takođe ključno Održavajte server i sigurnosne protokole ažurnimaSSLv3, TLS 1.0 i drugi zastarjeli protokoli moraju biti onemogućeni, 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 konfigurisanje servera s prihvatljivim nivoom sigurnosti.

Ništa manje važno nije Periodično provjeravajte pravila preusmjeravanja između HTTP i HTTPS protokola i 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 je dobra praksa.

Druga ključna mjera je Provjerite stranicu za miješani sadržajOvo posebno važi nakon migracija na HTTPS ili kada se instaliraju novi dodaci, teme ili eksterne 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 dijagnostički alati samih dobavljača omogućavaju vam analizu lanca certifikata, aktivnih protokola, kompatibilnosti preglednika i potencijalnih ranjivosti. Integriranje ovih pregleda u rutinske zadatke održavanja pomaže u otkrivanju grešaka prije nego što ih kupci primijete.

Kad se sve sabere, jasno je da Greške TLS certifikata i HTTPS stranice koje se ne učitavaju rijetko su uzrokovane "crnom magijom"Gotovo uvijek postoji zaboravljeni datum isteka, nepotpuna lozinka, pogrešno konfiguriran DNS ili jednostavno vremenska razlika na korisničkom 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 katanac.

Događaji u vezi sa Windowsom 11
Povezani članak:
Filtrirajte kritične događaje, upozorenja i greške pomoću Get-WinEvent-a