Кратак одговор
SSL грешка сертификата у коду најчешће настаје због истека сертификата, неповерења у ланац сертификата или погрешног хостнаме-а. Решава се провером датума, ажурирањем CA складишта и исправним конфигурисањем клијента, а не искључивањем провере.
Како се проблем препознаје
- Апликација баца грешку `CERT_HAS_EXPIRED` или `certificate has expired`
- Јавља се `UNABLE_TO_VERIFY_LEAF_SIGNATURE` или `self signed certificate in certificate chain`
- `ERR_TLS_CERT_ALTNAME_INVALID` због погрешног хостнаме-а
- Конекција ради у прегледачу, али не у коду
- Грешка се јавља само на једном окружењу (нпр. стагинг)
Најчешћи узроци
Истекао сертификат
Сертификат на серверу је истекао или је клијент у кешу сачувао старији ланац. Проверите датум важења и освежите кеш.
Неповерен издавалац (CA)
Клијент не препознаје CA који је издао сертификат, што је често код интерних или селф-сигнед сертификата. Потребно је додати CA у складиште поверења.
Погрешан хостнаме
Сертификат је издат за друго име (нпр. `example.com` уместо `api.example.com`). Проверите SAN поље и начин на који клијент приступа.
Неисправан ланац сертификата
Server не шаље комплетне интермедиате сертификате, па клијент не може да изгради ланац до корена. Решава се исправном конфигурацијом сервера.
Погрешно време на систему
Ако је сат на рачунару или контејнеру погрешан, валидан сертификат изгледа као истекао или још није важећи.
Решење корак по корак
- 1
Прочитајте тачну поруку грешке
У логу потражите код грешке (нпр.
CERT_HAS_EXPIRED,UNABLE_TO_VERIFY_LEAF_SIGNATURE,ERR_TLS_CERT_ALTNAME_INVALID). Различити кодови указују на различит узрок, па не прескачите овај корак. - 2
Проверите датум важења сертификата
Отворите сајт у прегледачу и кликните на катанац поред адресе, па у детаљима сертификата погледајте датум почетка и краја важења. Или у терминалу покрените
openssl s_client -connect host:443 -servername host -textи погледајте пољаNot BeforeиNot After. - 3
Проверите да ли се хостнаме поклапа
У истом
opensslизлазу пронађите пољеSubject Alternative Name. Оно мора да садржи име које користите у коду. Ако приступате преко IP адресе, сертификат вероватно неће бити валидан. - 4
Ажурирајте CA складиште на систему
На Windowsu (као администратор) покрените
certutil -generateSSTFromWU roots.sstпаcertutil -addstore root roots.sst; појединачни сертификат додајте саcertutil -addstore root sertifikat.crt. Додајте само CA којем верујете. На Linuxu (Дебиан/Убунту)sudo update-ca-certificates, а на macOS-u двоклик на.crt, додајте уSystemkeychain и поставитеAlways Trustза тај CA. - 5
Додајте интерни CA у код
Ако користите интерни или селф-сигнед сертификат, у коду проследите путању до CA фајла. У Node.js то је опција
caуhttps.requestили променљиваNODE_EXTRA_CA_CERTS=/putanja/do/ca.crt. У Pythonrequestsкориститеverify='/putanja/do/ca.crt'. - 6
Исправите ланац на серверу
Уверите се да server шаље пуне ланце сертификата. У Nginx конфигурацији
ssl_certificateтреба да садржи сертификат сервера и листу интермедиате сертификата, са сертификатом сервера на првом месту. Проверите алатомopenssl s_client -showcerts -servername host -connect host:443. - 7
Проверите време на систему
На Windowsu (као администратор)
w32tm /resync, на Linuxutimedatectlиsudo systemctl restart systemd-timesyncd. У Docker контејнерима проверите да ли је време синхронизовано са хостом. - 8
Привремено заобиђите проверу само у развоју
Ако морате да наставите развој, привремено онемогућите проверу, али никада у продукцији. У Node.js
NODE_TLS_REJECT_UNAUTHORIZED=0(само локално), у Pythonverify=Falseузurllib3.disable_warnings(). Обавезно уклоните пре commita.
Ако ништа не помогне: изолујте проблем
Ако грешка и даље постоји, направите минимални репродуктивни пример: скрипту која само успоставља TLS конекцију ка истом хосту. Тестирајте је са различитих мрежа и рачунара. Упоредите излаз openssl s_client са оним што клијент види. Проверите да ли proxy или антивирус пресрећу саобраћај и мењају сертификат. У Docker-у проверите да ли контејнер има инсталиране CA сертификате (ca-certificates пакет). Ако је проблем само на продукцији, упоредите конфигурацију окружења и верзије клијената. За сложене ланце и mTLS, користите алате као што су openssl verify и curl -v да видите тачан ток.
Како да спречите да се понови
- Редовно проверавајте датуме истека сертификата и поставите подсетнике
- Користите аутоматизовано обнављање (нпр. Лет'с Encrypt) и тестирајте обнову
- У развоју користите `mkcert` за локалне сертификате уместо трајног искључивања провере
- Никада не commit-ujte код који садржи `rejectUnauthorized: false` или `verify=False`
Када је боље позвати стручњака
Ако грешка укључује mTLS, сложене ланце сертификата или се јавља само на продукционим серверима, позовите IT подршку да изолује проблем без ризика од прекида рада.
Развој софтвера и производа · Апликације по мери, SaaS и MVP за 4 до 8 недељаЧеста питања
Зашто ми се јавља `self signed certificate in certificate chain`?
То значи да клијент не верује сертификату који је у ланцу, најчешће зато што је селф-сигнед или интерни CA. Решење је да додате тај CA у складиште поверења или да у коду проследите путању до CA фајла.
Да ли је безбедно искључити проверу сертификата у коду?
Не, искључивање провере (`rejectUnauthorized: false` или `verify=False`) чини апликацију рањивом на нападе пресретања. Користите га само привремено у локалном развоју и никада у продукцији.
Како да проверим који сертификат server заиста шаље?
Покрените `openssl s_client -connect host:443 -servername host -showcerts -text`. У излазу ћете видети све сертификате у ланцу, а текстуални део приказује детаље сертификата сервера, укључујући датуме важења и SAN поља.