Kratak odgovor
SSL greška sertifikata u kodu najčešće nastaje zbog isteka sertifikata, nepoverenja u lanac sertifikata ili pogrešnog hostname-a. Rešava se proverom datuma, ažuriranjem CA skladišta i ispravnim konfigurisanjem klijenta, a ne isključivanjem provere.
Kako se problem prepoznaje
- Aplikacija baca grešku `CERT_HAS_EXPIRED` ili `certificate has expired`
- Javlja se `UNABLE_TO_VERIFY_LEAF_SIGNATURE` ili `self signed certificate in certificate chain`
- `ERR_TLS_CERT_ALTNAME_INVALID` zbog pogrešnog hostname-a
- Konekcija radi u pregledaču, ali ne u kodu
- Greška se javlja samo na jednom okruženju (npr. staging)
Najčešći uzroci
Istekao sertifikat
Sertifikat na serveru je istekao ili je klijent u kešu sačuvao stariji lanac. Proverite datum važenja i osvežite keš.
Nepoveren izdavalac (CA)
Klijent ne prepoznaje CA koji je izdao sertifikat, što je često kod internih ili self-signed sertifikata. Potrebno je dodati CA u skladište poverenja.
Pogrešan hostname
Sertifikat je izdat za drugo ime (npr. `example.com` umesto `api.example.com`). Proverite SAN polje i način na koji klijent pristupa.
Neispravan lanac sertifikata
Server ne šalje kompletne intermediate sertifikate, pa klijent ne može da izgradi lanac do korena. Rešava se ispravnom konfiguracijom servera.
Pogrešno vreme na sistemu
Ako je sat na računaru ili kontejneru pogrešan, validan sertifikat izgleda kao istekao ili još nije važeći.
Rešenje korak po korak
- 1
Pročitajte tačnu poruku greške
U logu potražite kod greške (npr.
CERT_HAS_EXPIRED,UNABLE_TO_VERIFY_LEAF_SIGNATURE,ERR_TLS_CERT_ALTNAME_INVALID). Različiti kodovi ukazuju na različit uzrok, pa ne preskačite ovaj korak. - 2
Proverite datum važenja sertifikata
Otvorite sajt u pregledaču i kliknite na katanac pored adrese, pa u detaljima sertifikata pogledajte datum početka i kraja važenja. Ili u terminalu pokrenite
openssl s_client -connect host:443 -servername host -texti pogledajte poljaNot BeforeiNot After. - 3
Proverite da li se hostname poklapa
U istom
opensslizlazu pronađite poljeSubject Alternative Name. Ono mora da sadrži ime koje koristite u kodu. Ako pristupate preko IP adrese, sertifikat verovatno neće biti validan. - 4
Ažurirajte CA skladište na sistemu
Na Windowsu (kao administrator) pokrenite
certutil -generateSSTFromWU roots.sstpacertutil -addstore root roots.sst; pojedinačni sertifikat dodajte sacertutil -addstore root sertifikat.crt. Dodajte samo CA kojem verujete. Na Linuxu (Debian/Ubuntu)sudo update-ca-certificates, a na macOS-u dvoklik na.crt, dodajte uSystemkeychain i postaviteAlways Trustza taj CA. - 5
Dodajte interni CA u kod
Ako koristite interni ili self-signed sertifikat, u kodu prosledite putanju do CA fajla. U Node.js to je opcija
cauhttps.requestili promenljivaNODE_EXTRA_CA_CERTS=/putanja/do/ca.crt. U Pythonrequestskoristiteverify='/putanja/do/ca.crt'. - 6
Ispravite lanac na serveru
Uverite se da server šalje pune lance sertifikata. U Nginx konfiguraciji
ssl_certificatetreba da sadrži sertifikat servera i listu intermediate sertifikata, sa sertifikatom servera na prvom mestu. Proverite alatomopenssl s_client -showcerts -servername host -connect host:443. - 7
Proverite vreme na sistemu
Na Windowsu (kao administrator)
w32tm /resync, na Linuxutimedatectlisudo systemctl restart systemd-timesyncd. U Docker kontejnerima proverite da li je vreme sinhronizovano sa hostom. - 8
Privremeno zaobiđite proveru samo u razvoju
Ako morate da nastavite razvoj, privremeno onemogućite proveru, ali nikada u produkciji. U Node.js
NODE_TLS_REJECT_UNAUTHORIZED=0(samo lokalno), u Pythonverify=Falseuzurllib3.disable_warnings(). Obavezno uklonite pre commita.
Ako ništa ne pomogne: izolujte problem
Ako greška i dalje postoji, napravite minimalni reproduktivni primer: skriptu koja samo uspostavlja TLS konekciju ka istom hostu. Testirajte je sa različitih mreža i računara. Uporedite izlaz openssl s_client sa onim što klijent vidi. Proverite da li proxy ili antivirus presreću saobraćaj i menjaju sertifikat. U Docker-u proverite da li kontejner ima instalirane CA sertifikate (ca-certificates paket). Ako je problem samo na produkciji, uporedite konfiguraciju okruženja i verzije klijenata. Za složene lance i mTLS, koristite alate kao što su openssl verify i curl -v da vidite tačan tok.
Kako da sprečite da se ponovi
- Redovno proveravajte datume isteka sertifikata i postavite podsetnike
- Koristite automatizovano obnavljanje (npr. Let's Encrypt) i testirajte obnovu
- U razvoju koristite `mkcert` za lokalne sertifikate umesto trajnog isključivanja provere
- Nikada ne commit-ujte kod koji sadrži `rejectUnauthorized: false` ili `verify=False`
Kada je bolje pozvati stručnjaka
Ako greška uključuje mTLS, složene lance sertifikata ili se javlja samo na produkcionim serverima, pozovite IT podršku da izoluje problem bez rizika od prekida rada.
Razvoj softvera i proizvoda · Aplikacije po meri, SaaS i MVP za 4 do 8 nedeljaČesta pitanja
Zašto mi se javlja `self signed certificate in certificate chain`?
To znači da klijent ne veruje sertifikatu koji je u lancu, najčešće zato što je self-signed ili interni CA. Rešenje je da dodate taj CA u skladište poverenja ili da u kodu prosledite putanju do CA fajla.
Da li je bezbedno isključiti proveru sertifikata u kodu?
Ne, isključivanje provere (`rejectUnauthorized: false` ili `verify=False`) čini aplikaciju ranjivom na napade presretanja. Koristite ga samo privremeno u lokalnom razvoju i nikada u produkciji.
Kako da proverim koji sertifikat server zaista šalje?
Pokrenite `openssl s_client -connect host:443 -servername host -showcerts -text`. U izlazu ćete videti sve sertifikate u lancu, a tekstualni deo prikazuje detalje sertifikata servera, uključujući datume važenja i SAN polja.