SSL i HTTPS Enkripcija — Kompletni Vodič za Web Sigurnost 2026
SSL i HTTPS Enkripcija — Kompletni Vodič za Web Sigurnost 2026
Prema W3Techs podacima iz januara 2026, 87% svih sajtova koristi HTTPS — a Google aktivno penalizuje svaki sajt koji to ne radi.
Zamislite da ste uložili mjesece rada u izgradnju web sajta — savršen dizajn, optimizovan sadržaj, izgrađeni backlinkovi. A onda vaši posjetioci vide upozorenje "Not Secure" u pregledaču, a Google vas gura na dno rezultata pretrage. Upravo to se dešava sajtovima bez SSL/HTTPS enkripcije u 2026. godini. SSL certifikat više nije opcija — to je osnovni preduslov za svaki ozbiljan web projekat.
Zašto je HTTPS Obavezan u 2026. Godini?
Pitanje SSL certifikata odavno je prestalo biti tehničko pitanje — postalo je pitanje opstanka vašeg sajta u online prostoru. Razlozi su višestruki i međusobno povezani.
Globalna Adopcija
Prema W3Techs podacima iz januara 2026, 87% svih web sajtova koristi važeći SSL certifikat — skok sa svega 18,5% u 2016. godini.
Google Chrome
Prema Google podacima za 2025, čak 99% vremena pregledanja u Chrome-u provodi se na HTTPS stranicama — na svim platformama.
SEO Faktor
Od 2014. godine HTTPS je zvanični Google ranking signal. U 2025. i 2026. godini, sajtovi bez HTTPS-a dobijaju niže pozicije ili bivaju potpuno uklonjeni iz rezultata.
Google je još 2014. godine zvanično potvrdio HTTPS kao ranking signal u svom algoritmu. Prema istraživanjima, HTTPS direktno utiče na Page Experience signale — što znači da sajt bez SSL certifikata automatski gubi bodove u ukupnoj ocjeni iskustva korisnika. Osim toga, od kraja 2017. godine, Google aktivno označava HTTP sajtove kao "Not Secure" u Chrome-u, što drastično povećava stopu napuštanja stranice (bounce rate) i posredno šteti SEO pozicijama.
Šta se dešava sa sajtom bez HTTPS-a?
- ✗ Chrome i Firefox prikazuju upozorenje "Not Secure" u adresnoj traci
- ✗ Google rangira sajt niže u rezultatima pretrage (direktan SEO udar)
- ✗ Moderni pregledači blokiraju geolokaciju, kameru, mikrofon i Web Payment API
- ✗ Podaci korisnika (lozinke, forme) putuju u čistom tekstu — ranjivi na MITM napade
- ✗ HTTP/2 protokol nije dostupan — sporije učitavanje stranica
- ✗ OAuth 2.0 i moderne autentifikacijske biblioteke ne rade bez HTTPS-a
SSL vs TLS — Razlika Koju Treba Znati
Termini "SSL" i "TLS" često se koriste naizmjenično, ali postoji važna razlika. SSL (Secure Sockets Layer) je originalni protokol koji je razvio Netscape 1995. godine. TLS (Transport Layer Security) je njegov nasljednik — moderniji, sigurniji i jedini koji se danas zapravo koristi. Kada kažemo "SSL certifikat", tehnički mislimo na TLS certifikat, ali termin SSL se zadržao u svakodnevnoj upotrebi.
U 2026. godini, TLS 1.3 je standard, dok TLS 1.2 ostaje prisutan samo kod starijih enterprise sistema. TLS 1.0 i 1.1 su potpuno zastarjeli i blokirani od strane modernih pregledača.
Vrste SSL/TLS Certifikata — Koji Odabrati?
Svi SSL certifikati pružaju isti nivo enkripcije podataka. Razlika je u tome koliko se identitet vlasnika sajta provjerava — što direktno utiče na nivo povjerenja koji korisnici imaju prema sajtu.
| Tip Certifikata | Validacija | Izdavanje | Cijena | Preporučeno za |
|---|---|---|---|---|
| DV (Domain Validation) | Samo vlasništvo domene | Minuti | Besplatno – ~$50/god | Blogovi, portfelji, mali sajtovi |
| OV (Organization Validation) | Domena + identitet firme | 1–3 radna dana | $50 – $300/god | Poslovni sajtovi, korporativni portali |
| EV (Extended Validation) | Domena + pravni status + adresa | 1–7 dana | $200 – $700/god | Banke, e-commerce, vladini portali |
| Wildcard SSL | Domena + svi subdomeni (*.domena.com) | Minuti – sati | $100 – $500/god | SaaS platforme, multi-tenant aplikacije |
Prema analizi iz 2024. godine, oko 80% svih SSL certifikata su DV tip, a Let's Encrypt drži 63,7% tržišnog udjela zahvaljujući besplatnim DV certifikatima. Za većinu web projekata — blogova, poslovnih sajtova, SaaS aplikacija — DV certifikat je potpuno dovoljan. OV i EV certifikati su rezervisani za situacije gdje je pravni identitet organizacije kritičan faktor povjerenja.
Let's Encrypt — Besplatni SSL za Svakoga
Let's Encrypt je besplatni, automatizirani i otvoreni Certificate Authority koji je revolucionisao SSL tržište. Zahvaljujući njemu, svaki web sajt — bez obzira na budžet — može imati validan SSL certifikat koji pregledači potpuno podržavaju. Certbot je preporučeni ACME klijent za instalaciju Let's Encrypt certifikata.
Instalacija Let's Encrypt certifikata putem Certbota (Ubuntu/Nginx)
# 1. Instalacija Certbota
sudo apt update && sudo apt install certbot python3-certbot-nginx
# 2. Generisanje certifikata za domenu
sudo certbot --nginx -d example.com -d www.example.com
# 3. Testiranje automatskog obnavljanja
sudo certbot renew --dry-run
# 4. Provjera certifikata
sudo certbot certificates
Certbot automatski konfigurira Nginx za HTTPS i postavlja cron job za automatsko obnavljanje certifikata prije isteka.
Let's Encrypt certifikati su važeći 90 dana. Certbot automatski postavlja cron job koji obnavlja certifikat kada mu ostane manje od 30 dana do isteka — tako da ne morate brinuti o ručnom obnavljanju. Ovo je posebno važno u kontekstu nadolazećih promjena: od marta 2026. godine, maksimalni rok važenja TLS certifikata smanjuje se na 200 dana, a do 2029. na svega 47 dana, što čini automatizaciju obnavljanja apsolutno obaveznom.
Nginx Konfiguracija — HTTP na HTTPS Redirect
Nakon instalacije SSL certifikata, ključno je pravilno konfigurisati web server da sve HTTP zahtjeve automatski preusmjerava na HTTPS. Evo kompletne Nginx konfiguracije za Next.js aplikaciju:
Nginx konfiguracija za Next.js + SSL (nginx.conf)
# HTTP blok — redirect na HTTPS (301 permanent)
server {
listen 80 default_server;
server_name example.com www.example.com;
location / {
return 301 https://$server_name$request_uri;
}
}
# HTTPS blok — reverse proxy za Next.js
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Reverse proxy na Next.js (port 3000)
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Next.js Konfiguracija za HTTPS
Next.js aplikacije imaju nekoliko pristupa za implementaciju HTTPS-a, u zavisnosti od okruženja i načina deployanja.
1. Next.js Middleware — Automatski HTTPS Redirect
Najelegantniji način da prisilite HTTPS na nivou aplikacije je putem Next.js Middlewarea. Ovaj kod se izvršava prije svakog zahtjeva:
// middleware.ts
import
{ NextResponse }from
'next/server';import type
{ NextRequest }from
'next/server';export function
middleware(req: NextRequest) {if (process.env.NODE_ENV === 'production' &&
req.headers.get('x-forwarded-proto') !== 'https') {
return
NextResponse.redirect(`https://${req.headers.get('host')}${req.nextUrl.pathname}`,
301
);
}
}
2. HSTS Header u next.config.js
HTTP Strict Transport Security (HSTS) header govori pregledaču da uvijek koristi HTTPS za ovaj domen — čak i ako korisnik ukuca http:// u adresnu traku:
// next.config.js
const nextConfig = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Strict-Transport-Security',
value: 'max-age=63072000; includeSubDomains; preload'
}
]
}
];
}
};
module.exports
= nextConfig;3. HTTPS za Lokalni Razvoj (Next.js Dev Server)
Next.js podržava generisanje self-signed certifikata za lokalni razvoj. Ovo je korisno za testiranje OAuth 2.0, Service Workers i PWA funkcionalnosti:
# Pokretanje Next.js dev servera sa HTTPS-om
next dev --experimental-https
# Ili putem mkcert alata za lokalno pouzdane certifikate
mkcert -install
mkcert localhost
Napomena: Self-signed certifikati su isključivo za lokalni razvoj. U produkciji uvijek koristite certifikate od pouzdanih Certificate Authorities.
4. Vercel Deployment — Automatski HTTPS
Ako deployate Next.js aplikaciju na Vercel ili Netlify, HTTPS je automatski konfigurisan bez ikakvog dodatnog posla:
- ✓ Vercel — automatski konfiguriše HTTPS za sve deployane aplikacije, uključujući custom domene
- ✓ Netlify — automatski SSL certifikat putem Let's Encrypt za svaki deploy
- ✓ AWS Amplify — integrisan SSL management putem AWS Certificate Manager
HSTS — Napredna Zaštita od SSL Stripping Napada
HTTP Strict Transport Security (HSTS) je sigurnosni mehanizam koji pregledaču govori da sajt treba uvijek pristupati isključivo putem HTTPS-a. Prema MDN Web Docs dokumentaciji, HSTS header automatski nadograđuje sve buduće HTTP zahtjeve na HTTPS, a pregledač ne dozvoljava korisniku da zaobiđe greške sa nevažećim certifikatom.
Jeste li znali?
Prema podacima iz SSL Pulse izvještaja za jun 2025, čak 28,7% od 134.380 analiziranih popularnih sajtova ne prati best practices za SSL implementaciju — uključujući nepotpune certificate chains i slabe enkripcijske cipher-e. Čak i kada imate SSL certifikat, pogrešna konfiguracija može vas ostaviti ranjivim.
HSTS štiti od tzv. SSL stripping napada — situacije kada napadač transparentno pretvara HTTPS vezu u HTTP, a korisnik nema način da to primijeti. Kada pregledač jednom primi HSTS header, automatski nadograđuje sve HTTP zahtjeve na HTTPS bez da uopšte kontaktira server.
Preporučena HSTS konfiguracija prema OWASP smjernicama i Google Chrome Lighthouse auditu:
# Preporučena HSTS konfiguracija (max-age = 2 godine)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
# Apache konfiguracija
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# Nginx konfiguracija
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
Česte Greške pri SSL Implementaciji
| Greška | Učestalost | Posljedica | Rješenje |
|---|---|---|---|
| Istekli certifikat | ~15% outage-a | Browser upozorenje, gubitak povjerenja | Automatsko obnavljanje (Certbot cron) |
| Mixed Content | ~12% sajtova | HTTP resursi na HTTPS stranici blokirani | Ažurirati sve URL-ove na HTTPS |
| Zastarjeli cipher-i | ~9% servera | Ranjivost na kriptoanalitičke napade | Koristiti TLS 1.3, AES-256-GCM |
| Redirect petlja | ~7% sajtova | Sajt nedostupan, beskonačni redirect | Provjera x-forwarded-proto headera |
| Nedostaje HSTS header | Česta greška | Ranjivost na SSL stripping napade | Dodati HSTS u server konfiguraciju |
Best Practices za SSL/HTTPS u 2026. Godini
Kompletna SSL Sigurnosna Čeklista
- ✓ Koristite TLS 1.3 — najnoviji i najsigurniji protokol; TLS 1.0 i 1.1 su zastarjeli
- ✓ Automatizujte obnavljanje certifikata — od 2026. maksimalni rok je 200 dana, a do 2029. biće 47 dana
- ✓ Implementirajte HSTS header sa max-age od najmanje godinu dana i includeSubDomains direktivom
- ✓ 301 Permanent Redirect — koristite 301 (ne 302) za HTTP→HTTPS redirect radi SEO vrijednosti
- ✓ Eliminirajte Mixed Content — svi resursi (slike, skripte, fontovi) moraju se učitavati putem HTTPS-a
- ✓ Testirajte SSL konfiguraciju — koristite Qualys SSL Labs alat za besplatnu provjeru i ocjenu (ciljajte A+)
- ✓ ECDSA certifikati — u Q1 2026, ECDSA je dostigao 42,9% udjela (rast sa 34,5% u Q4 2025) zbog bolje performanse
- ✓ Certificate Transparency — svi javni certifikati su obavezno logovani od 2018, što omogućava detekciju lažnih certifikata
Nadolazeće Promjene — Kratkoročni SSL Certifikati
Industrija SSL certifikata prolazi kroz značajne promjene koje će direktno uticati na sve web developere i DevOps timove. CA/Browser Forum je usvojio plan postepenog smanjivanja roka važenja certifikata:
Sadašnji Standard
Maksimalni rok važenja TLS certifikata smanjuje se na 200 dana, uz smanjenje DCV reuse perioda.
Sljedeći Korak
Dalji nastavak smanjivanja — organizacije bez automatizacije moraće obnavljati certifikate svakih ~3 mjeseca.
Konačni Cilj
Finalni rok — praktično mjsečno obnavljanje. Bez automatizirane upravljanja certifikatima, ovo je nemoguće ručno pratiti.
Ova promjena nije samo sigurnosna politika — ona je forcing function za automatizaciju. Alati poput Certbota, ACME protokola i platformi kao što su Cloudflare, Vercel i AWS Certificate Manager postaju neophodni za svaki ozbiljan web projekat. Organizacije koje se i dalje oslanjaju na ručno obnavljanje certifikata suočit će se s ozbiljnim operativnim problemima.
"HTTPS je kao sigurnosni pojas u automobilu. Ne čini vas bržim vozačem, ne garantuje pobjedu na utrci — ali bez njega ne biste smjeli ni krenuti. U 2026. godini, svaki ozbiljan web sajt mora imati SSL certifikat. Bez iznimke.
— Ilustrativan citat, Senior Web Security Engineer
SSL i Kvantni Računari — Pogled u Budućnost
Dok je trenutna AES-256 enkripcija praktično neprobojna za klasične računare — procjenjuje se da bi probijanje jednog session key-a trajalo duže od starosti svemira — industrija se već priprema za tzv. "Q-Day". Prema NIST smjernicama za 2025/2026. godinu, standardni RSA-2048 certifikati mogli bi biti ranjivi na kvantne računare do 2030. godine. Ovo je razlog zašto se već sada radi na Post-Quantum Cryptography (PQC) standardima.
SSL/HTTPS enkripcija u 2026. godini nije opcija — to je osnova svakog web projekta. Sa 87% sajtova koji već koriste HTTPS, sa Google-om koji aktivno penalizuje nezaštićene sajtove i sa pregledačima koji blokiraju ključne funkcionalnosti na HTTP sajtovima, pitanje više nije "da li mi treba SSL" već "koji SSL certifikat odabrati i kako ga pravilno konfigurisati". Besplatni Let's Encrypt certifikati sa Certbot automatizacijom čine ovu implementaciju dostupnom svima, dok Next.js Middleware i HSTS headeri osiguravaju da svaki posjetilac vašeg sajta uvijek komunicira putem šifrovane veze. Uz nadolazeće smanjivanje rokova važenja certifikata na 47 dana do 2029. godine, automatizacija SSL managementa postaje kritična infrastrukturna odluka za svaki ozbiljan web projekat.
