Kā pagarināt SSL sertifikātu
SSL/TLS sertifikāta pagarināšana (atjaunošana) ir regulārs uzturēšanas process, kas nodrošina, ka jūsu vietne turpina strādāt ar HTTPS bez pārlūku brīdinājumiem un bez pārtraukumiem. Lielākā daļa “SSL incidentu” notiek nevis uzstādīšanas brīdī, bet tieši tad, kad sertifikāts beidzas un netiek laicīgi atjaunots. Pārlūki kļūst arvien stingrāki: beidzies sertifikāts nozīmē brīdinājumu, uzticības kritumu un bieži arī konversiju kritumu. Tāpēc pareiza pieeja ir uztvert sertifikātu kā infrastruktūras “dzīvu” komponenti, kas jāuzrauga un jāatjauno automātiski.
Atjaunošanas darbības atšķiras atkarībā no tā, kāds sertifikāts tiek izmantots. Let’s Encrypt sertifikāti parasti ir derīgi 90 dienas un paredzēti automatizācijai ar ACME klientu (piemēram, certbot). Komerciāli DV/OV/EV sertifikāti bieži ir derīgi ilgāk (piemēram, 1 gads vai vairāk), bet to atjaunošanai var būt vajadzīga atkārtota validācija un jauna sertifikāta izsniegšana. Tomēr abos gadījumos servera pusē jūs gandrīz vienmēr “uzliekat” jaunu sertifikāta failu un pārlādējat web serveri, lai tas sāktu lietot atjaunoto sertifikātu.
Ja jūs izmantojat CloudHosting risinājumus, atjaunošanas scenāriju var vienkāršot, izvēloties pareizo servisa modeli. Ja jums vajag konkrētu sertifikāta veidu (DV/OV/EV, wildcard vai multi-domain), skatiet SSL sertifikātus. Ja jūs vēlaties, lai ikdienas uzturēšana ir vienkāršāka, bieži izvēlas hostingu. Ja jums nepieciešama pilna kontrole un pielāgoti scenāriji (piemēram, vairākas lietotnes, reverse proxy, atsevišķi servisi), piemērotāki ir virtuālie serveri.
1) Pirmā lieta: noskaidrojiet, kāda tipa sertifikāts jums ir
Pirms atjaunošanas ir svarīgi zināt, vai sertifikāts ir Let’s Encrypt (ACME) vai komerciāls. To var saprast pēc sertifikāta izsniedzēja (Issuer) un derīguma termiņa. Let’s Encrypt sertifikāti parasti atjaunojas automātiski, ja ir pareizi iestatīts certbot (vai cits ACME klients) un validācijas metode turpina strādāt. Komerciāli sertifikāti parasti prasa atkārtotu izsniegšanu: jūs saņemat jaunu sertifikātu (bieži ar jaunu derīguma termiņu), un tad to uzstādāt serverī.
Praktiski ieteikums ir neatlikt uz pēdējo brīdi. Sāciet atjaunošanas plānu vismaz 2–3 nedēļas pirms termiņa, īpaši, ja tas ir OV/EV un vajadzīga organizācijas validācija. Let’s Encrypt gadījumā automatizācija atjauno krietni agrāk, bet ir vērts regulāri pārbaudīt, vai tā joprojām darbojas, jo infrastruktūras izmaiņas (DNS migrācija, ugunsmūris, reverse proxy) var pēkšņi salauzt validāciju.
2) Pārbaudiet derīguma termiņu un aptvertos domēnus
Atjaunošanas laikā bieži atklājas “klasiskā” problēma: sertifikāts sedz tikai vienu hostname (piemēram, www), bet lietotāji apmeklē arī saknes domēnu, vai arī parādījies jauns apakšdomēns (api, shop, cp). Pēc tam vietne “daļēji” strādā, bet daļā gadījumu parādās name mismatch kļūda. Tāpēc pirms atjaunošanas pārskatiet, kuri vārdi (SAN) sertifikātā ir vajadzīgi, un atjaunošanas brīdī iekļaujiet visus aktuālos.
# Pārbaudīt termiņu un SAN no servera puses openssl s_client -connect example.lv:443 -servername example.lv 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName
Ja jūs maināt sertifikāta pārklājumu (piemēram, pievienojat jaunu apakšdomēnu), tā jau ir “reissue” situācija: tiek izdots jauns sertifikāts. Let’s Encrypt gadījumā tas nozīmē izpildīt certbot komandu ar papildu -d parametriem; komerciāla sertifikāta gadījumā tas var būt jauns pasūtījums vai esošā sertifikāta pārizsniegšana atkarībā no CA politikas.
3) Let’s Encrypt atjaunošana: certbot, validācija un automātika
Let’s Encrypt filozofija ir automatizācija. Tipiskā serverī certbot tiek palaists ar cron vai systemd timer, un tas atjauno sertifikātu, ja termiņš tuvojas. Jūsu uzdevums ir pārliecināties, ka: a) atjaunošanas komanda tiek izpildīta regulāri, b) validācijas metode (HTTP-01 vai DNS-01) nav salauzta, un c) pēc atjaunošanas web serveris veic reload. Ja trūkst kāds no šiem posmiem, sertifikāts var beigties “klusām”, līdz brīdim, kad lietotāji sāk redzēt brīdinājumus.
# Sausais tests (drošs) certbot renew --dry-run # Reāla atjaunošana (ja nepieciešams) certbot renew
HTTP-01 validācijai ir vajadzīgs pieejams ports 80 un pareizi maršrutēta /.well-known/acme-challenge/ sadaļa līdz jūsu serverim. Ja jūs esat ieslēdzis stingru pāradresāciju vai reverse proxy, pārliecinieties, ka challenge fails tomēr ir sasniedzams. DNS-01 validācijai jāspēj korekti izveidot TXT ierakstu DNS zonā; tas ir īpaši svarīgi wildcard sertifikātiem. DNS-01 priekšrocība ir tā, ka tai nav vajadzīgs ports 80, bet tai ir jārēķinās ar DNS izplatīšanās laiku.
Pēc atjaunošanas bieži vajag reload, lai Nginx/Apache ielādētu jaunos failus. Labā prakse ir izmantot deploy hook, kas automātiski izpilda reload tikai tad, kad sertifikāts patiesi ir atjaunots. Tas samazina liekus reload un padara procesu determinētu. Ja jūs atjaunojat sertifikātu vairākām vietnēm, pārliecinieties, ka hooks neizraisa konflikta situācijas, un ka reload tiek veikts pareizajam servisam.
4) Komerciāla sertifikāta atjaunošana: CSR un jauns sertifikāts
Komerciālu sertifikātu atjaunošana parasti nozīmē: jūs ģenerējat jaunu CSR (ieteicams), iesniedzat to CA, iziet validāciju (DV vai OV/EV), un saņemat jaunu sertifikātu failu komplektu. Pat ja CA ļauj izmantot veco CSR, drošāk ir ģenerēt jaunu privāto atslēgu periodiski, jo tā samazina risku, ka ilgstoši lietots atslēgu pāris kādreiz tiks kompromitēts. Pēc tam jūs uzstādāt jauno sertifikātu serverī un pārlādējat web serveri.
# Jauna CSR + atslēga (RSA piemērs) openssl req -new -newkey rsa:2048 -nodes -keyout example.lv.key -out example.lv.csr
Svarīga detaļa: daudzām problēmām pamatā ir ķēde. CA parasti dod starpsertifikātus (intermediate), un serverim jānosūta pilna ķēde, nevis tikai “leaf” sertifikāts. Ja pēc atjaunošanas daļa klientu sāk sūdzēties, bieži iemesls ir tieši nepilna ķēde vai nepareiza secība. Tāpēc pēc katras atjaunošanas pārbaudiet, ko serveris sūta klientam, un vai ķēde ir korekta.
5) Pārbaude pēc atjaunošanas: ko obligāti izdarīt
Pēc sertifikāta atjaunošanas pārbaudiet vismaz trīs aspektus: vai serveris tiešām sāka izmantot jauno sertifikātu (derīguma datumi mainījās), vai sertifikāts sedz pareizos hostnames, un vai nav parādījušās papildus kļūdas (mixed content vai “wrong certificate”). Vienmēr pārbaudiet no vairākām vietām: ja jums ir CDN vai reverse proxy, var būt situācija, ka edge pusē sertifikāts ir jauns, bet origin pusē – vecs (vai otrādi). Tāpat, ja jums ir vairākas IP adreses vai load balancer, pārliecinieties, ka atjaunojāt visus mezglus.
openssl s_client -connect example.lv:443 -servername example.lv | openssl x509 -noout -dates -subject curl -I https://example.lv
Ja izmantojat HSTS, atjaunošanas disciplīna ir vēl svarīgāka, jo pārlūks “neatļaus” pāriet uz HTTP pat īslaicīgi. Tas nozīmē, ka pat īss sertifikāta izbeigšanās periods var kļūt par ļoti redzamu incidentu. Tāpēc HSTS ievieš tikai tad, kad atjaunošana ir automatizēta, testēta un uzraudzīta. Ja jūs šo procesu uztverat nopietni, HTTPS kļūst par stabilu standartu, nevis par periodisku krīzi.
6) Biežākie iemesli, kāpēc atjaunošana neizdodas
Praktiski neveiksmju cēloņi ir atkārtojoši. Let’s Encrypt gadījumā biežākie ir: ports 80 vairs nav pieejams, DNS ir pārslēgts uz citu IP, .well-known ceļš vairs nenorāda uz pareizo webroot, vai reverse proxy filtrē ACME pieprasījumus. DNS-01 gadījumā problēmas bieži ir TXT ierakstu kļūdās un DNS izplatīšanās laikos. Komerciāliem sertifikātiem klupšanas akmens var būt nepabeigta validācija, nokavēti dokumenti OV/EV, vai nepareizi ielikta intermediate ķēde.
Vēl viens biežs gadījums ir “aizmirsām par www” vai “aizmirsām par jaunu apakšdomēnu”. Sertifikāts tiek atjaunots, bet klienti atver hostname, kas nav sertifikātā, un redz kļūdu. Tāpēc atjaunošana ir labs brīdis pārskatīt domēnu karti un sakārtot pāradresācijas: izvēlēties kanonisko domēnu, pāradresēt alternatīvas un uzturēt vienotu politiku.
7) Operacionāla prakse: uzraudzība un brīdinājumi
Pat ar automatizāciju, uzraudzība ir vajadzīga. Laba prakse ir iestatīt monitoringu, kas pārbauda sertifikāta termiņu un brīdina, ja termiņš ir zem noteikta sliekšņa (piemēram, 14 vai 30 dienas). Tas pasargā no “klusajām” problēmām, ja automātika pārstāj darboties. Papildus var monitorēt arī ACME logus, web servera reload statusu un HTTP atbildes kodus, kas norāda uz drošības vai konfigurācijas regresiju.
Stabils HTTPS ilgtermiņā: process, nevis vienreizēja darbība
SSL sertifikāta pagarināšana ir īstais brīdis sakārtot procesu: pārliecināties par pareizu domēnu pārklājumu, atjaunošanas automatizāciju, drošu TLS konfigurāciju un testu pēc izmaiņām. Ja šie elementi ir sakārtoti, sertifikāta atjaunošana kļūst par rutīnu, nevis par ugunsgrēka dzēšanu. Praktiski tas nozīmē mazāk incidentu, labāku uzticību un stabilu lietotāju pieredzi neatkarīgi no tā, vai jūs izmantojat Let’s Encrypt vai komerciālu CA.
Ja jums ir sarežģītāka infrastruktūra, atcerieties, ka sertifikāts var būt vairākās vietās: CDN/edge, load balancer, reverse proxy, origin serveris. Atjaunošanas brīdī pārliecinieties, ka visi posmi ir atjaunoti un saskaņoti. Labi definēts process ar skaidru atbildību, pārbaudēm un brīdinājumiem ir visdrošākā garantija, ka HTTPS nekad nepārtrauks jūsu biznesa kritiskās plūsmas.