Kas ir SSL sertifikāti: kā darbojas HTTPS un kāpēc tas ir vajadzīgs mājaslapai

Kas ir SSL sertifikāti un kam tie vajadzīgi?

SSL/TLS sertifikāts ir digitāls “dokuments”, kas pierāda, ka jūs tiešām kontrolējat konkrētu domēnu, un ļauj izveidot šifrētu savienojumu starp pārlūku un serveri. Ikdienā mēs sakām “SSL”, bet tehniski mūsdienās gandrīz vienmēr tiek izmantots TLS protokols. Rezultāts lietotājam ir redzams kā https://, slēdzenīte pārlūkā un droša datu apmaiņa bez “noklausīšanās” riska.

Bez sertifikāta (vai ar nepareizi uzstādītu sertifikātu) pārlūks var rādīt brīdinājumus, daļa funkciju var nedarboties (piemēram, maksājumi, autorizācija, API), un Google/modernās pārlūkprogrammas šādas lapas uztver kā mazāk uzticamas. Tāpēc SSL sertifikāts vairs nav “opcijas drošībai” – tas ir pamata standarts jebkurai vietnei, kur notiek jebkāda datu ievade: pieteikšanās, formas, grozs, maksājumi, klientu zona, e-pasts vai integrācijas.

Kā SSL/TLS strādā: vienkāršs skaidrojums

Kad apmeklētājs atver jūsu vietni, pārlūks un serveris veic tā saucamo “handshake” jeb sasveicināšanos. Šajā procesā:

• serveris nosūta sertifikātu ar domēna nosaukumu un publisko atslēgu;
• pārlūks pārbauda, vai sertifikātu ir izsniedzusi uzticama sertifikācijas iestāde (CA) un vai tas nav beidzies/atsaukts;
• ja viss ir korekti, pārlūks un serveris vienojas par šifrēšanas parametriem un izveido šifrētu kanālu.

No šī brīža visi dati (paroles, sesijas, formas, maksājumu plūsma, API atbildes) tiek šifrēti. Pat ja kāds pārtver trafiku (piemēram, publiskā Wi-Fi), viņš redzēs tikai šifrētu “troksni”, nevis saturu.

Ko tieši dod SSL sertifikāts

• Šifrēšana: aizsargā datus pārsūtē, samazina MITM risku.
• Autentiskums: pārlūks var pārbaudīt, ka pieslēdzas pareizajam domēnam, nevis viltotam serverim.
• Datu integritāte: ceļā dati netiek nemanāmi izmainīti.
• Uzticamība un UX: bez brīdinājumiem, ar “drošas vietnes” indikatoru.
• Tehniskās prasības: HTTP/2, modernās pārlūkprogrammu politikas, daļa API un maksājumu vārteju prasa HTTPS.

SSL veidi: DV, OV, EV un ko izvēlēties

Sertifikāti atšķiras pēc validācijas līmeņa:

• DV (Domain Validation) – tiek pārbaudīts, ka jūs kontrolējat domēnu (praktiski vispopulārākais variants, pietiek vairumam projektu).
• OV (Organization Validation) – papildus domēnam tiek pārbaudīta organizācija; noder B2B un uzņēmumu portāliem, kur svarīga juridiska identitāte.
• EV (Extended Validation) – visstingrākā pārbaude. Mūsdienās pārlūki vairs neizceļ EV tik uzkrītoši kā agrāk, bet tas joprojām var būt prasība atsevišķās nozarēs.

Svarīgi: šifrēšanas līmenis praktiski ir līdzīgs visiem – atšķiras validācijas process un “uzticības konteksts”. Ja jūsu mērķis ir droši HTTPS un laba SEO/UX, DV sertifikāts parasti ir pietiekams.

Wildcard un SAN: kad vajag vairāk par vienu domēnu

Ja jums ir vairāki apakšdomēni (piemēram, www, mail, cpanel, api), var būt izdevīgi izvēlēties:

• Wildcard – aptver visus pirmā līmeņa apakšdomēnus, piem., *.example.lv.
• SAN / Multi-Domain – vienā sertifikātā var iekļaut vairākus dažādus domēnus un apakšdomēnus.

Izvēle atkarīga no arhitektūras: e-komercijai ar vairākām sadaļām apakšdomēnos wildcard ir ērts, bet uzņēmumam ar vairākiem domēniem – SAN.

Kā tiek izsniegts sertifikāts: CSR, validācija un ķēde

Lai izsniegtu sertifikātu, serverī parasti ģenerē CSR (Certificate Signing Request). CSR satur publisko atslēgu un informāciju par domēnu. Privātā atslēga paliek tikai pie jums – to nekad nesūta CA. Pēc validācijas CA izsniedz sertifikātu un starpsertifikātus (intermediate), kas veido uzticības ķēdi līdz “root”. Ja ķēde nav uzstādīta pareizi, pārlūks var rādīt kļūdas pat tad, ja pats sertifikāts ir derīgs.

Pārbaudīt sertifikātu no klienta puses (vienkārši):
openssl s_client -connect example.lv:443 -servername example.lv

Pārbaudīt ar curl:
curl -I https://example.lv

Let’s Encrypt un automātiska atjaunošana

Let’s Encrypt ir plaši izmantots bezmaksas CA, kas izsniedz DV sertifikātus ar īsu derīguma termiņu (parasti 90 dienas), bet paredz automatizētu atjaunošanu. Lielākā daļa problēmu ar SSL nav “izsniegšana”, bet gan atjaunošana vai neatbilstība konfigurācijā. Tāpēc mērķis ir process:

• automātiski atjaunot sertifikātu pirms termiņa;
• pārliecināties, ka pēc atjaunošanas servisi tiek pārlādēti (nginx/apache);
• izvairīties no “downtime” un brīdinājumiem.

TLS versijas, šifri un mūsdienu drošības iestatījumi

“SSL” vēsturiski ietver vairākas protokola paaudzes, bet mūsdienās drošs standarts ir TLS 1.2 un TLS 1.3. Vecie SSLv3 un TLS 1.0/1.1 tiek uzskatīti par novecojušiem, un daudzos klientus tie vairs pat netiek atbalstīti. Servera pusē laba prakse ir atļaut tikai TLS 1.2+ un izmantot modernus šifrus (cipher suites), kas balstās uz drošu atslēgu apmaiņu (piemēram, ECDHE) un mūsdienu šifrēšanu (AES-GCM vai ChaCha20-Poly1305).

Praktiski tas nozīmē mazāk risku un labāku saderību ar drošības prasībām. Ja jums ir ļoti veci klienti vai specifiskas ierīces (piemēram, industriālas iekārtas), jāsabalansē drošība un savietojamība, bet publiskām vietnēm ieteikums ir vienkāršs: neuzturēt novecojušus protokolus tikai “katram gadījumam”.

SNI, vairāki domēni un “kāpēc dažreiz redz nepareizu sertifikātu”

Mūsdienu hostinga un VPS scenārijos uz viena IP adreses bieži dzīvo vairāki domēni. Lai serveris zinātu, kuru sertifikātu pasniegt, tiek izmantots SNI (Server Name Indication): pārlūks “handshake” laikā pasaka, kuru domēnu atver. Ja klients ir ļoti vecs un SNI neatbalsta, var parādīties nepareizs sertifikāts. Šis ir rets, bet reizēm sastopams gadījums, un to risina vai nu ar atsevišķu IP, vai ar saderīgāku arhitektūru.

OCSP stapling un sertifikāta statusa pārbaude

Pārlūks var pārbaudīt, vai sertifikāts nav atsaukts (revoked). Lai šo procesu paātrinātu un samazinātu atkarību no ārējām OCSP sistēmām, serveris var izmantot OCSP stapling – tas “pielīmē” svaigu statusa atbildi pie TLS sarunas. Rezultāts: ātrāks savienojums un mazāk problēmu, ja CA OCSP infrastruktūra ir lēna.

HTTPS pāradresācijas un drošības galvenes

Lai lietotāji vienmēr nonāktu drošajā versijā, parasti iestata 301 pāradresāciju no HTTP uz HTTPS. Pēc tam var pievienot drošības galvenes:

• HSTS – liek pārlūkam turpmāk vienmēr izmantot HTTPS (ieviesiet pakāpeniski, ar saprātīgu max-age).
• Content-Security-Policy (CSP) – palīdz samazināt XSS riskus, kontrolējot, no kurienes drīkst ielādēt resursus.
• Secure/HttpOnly/SameSite cookies – pareiza sesiju cookie aizsardzība.

Šīs lietas nav obligātas, lai sertifikāts “strādātu”, bet tās padara HTTPS par pilnvērtīgu drošības slāni, nevis tikai slēdzenīti pārlūkā.

Testēšana pēc izmaiņām: ko pārbaudīt bez pārlūka

Pārbaudīt derīguma termiņu un SAN:
openssl s_client -connect example.lv:443 -servername example.lv 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

Pārbaudīt protokolu atbalstu (vienkārši):
openssl s_client -tls1_2 -connect example.lv:443 -servername example.lv
openssl s_client -tls1_3 -connect example.lv:443 -servername example.lv

Biežākās SSL kļūdas un kā tās izskatās praksē

• Sertifikāts beidzies – pārlūkā parādās brīdinājums; bieži iemesls ir salūzusi auto-atjaunošana.
• Nepareizs domēns – sertifikāts izdots www, bet lietotājs atver “plikā” domēnu (vai otrādi).
• Nav pilnas ķēdes – īpaši vecākās ierīcēs vai specifiskos klientu tīklos rodas kļūdas.
• Mixed content – lapa ir HTTPS, bet attēli/skripti ielādējas ar HTTP, un pārlūks tos bloķē.
• HSTS bez plāna – ieslēgts HSTS, bet pēc tam domēns/sertifikāts netiek uzturēts, un lietotāji “iesprūst” ar brīdinājumu.

SSL un CDN/proxy: “kurā pusē” atrodas sertifikāts

Ja izmantojat CDN vai reverse proxy (piemēram, lai kešotu saturu vai paslēptu izcelsmes serveri), sertifikāts var būt vajadzīgs divās vietās: pie CDN malas (edge) un arī starp CDN un jūsu izcelsmes serveri. Drošākais režīms ir “end-to-end” šifrēšana, kur HTTPS ir gan klienta pusē, gan arī starp starpnieku un serveri. Pretējā gadījumā var rasties situācija, kur ārēji viss ir HTTPS, bet iekšējais posms ir HTTP.

Kur SSL parasti uzstāda: hostings, VPS vai atsevišķs serveris

Uzstādīšanas process atkarīgs no tā, kur atrodas jūsu projekts. Pārvaldītā vidē (hostings) sertifikāta uzstādīšana bieži ir vienkāršāka, jo panelis automatizē gan izsniegšanu, gan atjaunošanu. Ja jums vajag pilnu kontroli, pielāgotu konfigurāciju, savus servisus vai īpašus portus, biežāk izvēlas VPS.

CloudHosting piedāvā atsevišķu pakalpojumu SSL risinājumiem SSL sertifikāti, kā arī pārvaldītu hostingu un elastīgus virtuālos serverus.

Ātrs kontrolsaraksts: ko pārbaudīt pēc SSL uzstādīšanas

1) Vai https:// atveras bez brīdinājumiem
2) Vai sertifikāts sedz gan example.lv, gan www.example.lv (ja vajag)
3) Vai uzstādīta pilna ķēde (intermediate)
4) Vai ir pāradresācija http -> https
5) Vai nav mixed content (pārlūka Console)
6) Vai auto-atjaunošana strādā (cron/systemd timer)

Noslēgumā: SSL sertifikāts ir pamats drošam, modernam un uzticamam web servisam. Tas vienlaikus risina šifrēšanu, autentifikāciju un integritāti, un īpaši ietekmē e-komerciju, klientu zonas un jebkuru projektu, kur tiek apstrādāti lietotāju dati.

SSL kā standarts: drošība, uzticība un uzturēšana ilgtermiņā

SSL/TLS nav “vienreiz uzlikt un aizmirst”. Stabils rezultāts ir process: pareiza domēnu pārklāšana (www/apakšdomēni), korekta ķēde, drošas pāradresācijas, regulāra atjaunošana un tests pēc izmaiņām. Laba prakse ir automatizēt atjaunošanu, uzturēt konsekventu konfigurāciju un pēc katras izmaiņas pārbaudīt no vairākām ierīcēm/tīkliem.

Ja jūs uztverat HTTPS kā infrastruktūras kvalitātes kritēriju, jūs iegūstat mazāk incidentu, labāku lietotāja pieredzi un mazāk risku gan reputācijai, gan drošībai.