Uzticams SSL atjaunošanas process bez dīkstāves
Publicēts 2026. gada 18. oktobrī
SSL atjaunošanas process jāsāk labu laiku pirms sertifikāta derīguma termiņa beigām, iepriekš pārbaudot sertifikātu uzskaiti, piekļuvi DNS un izvietošanas ceļu. Sertifikāta atjaunošana parasti ir ikdienišķa procedūra. Pārtraukumi rodas ar to saistītu problēmu dēļ: aizmirsts apakšdomēns, validācijas ieraksts pievienots nepareizai DNS zonai vai jauns sertifikāts instalēts vienā serverī, kamēr datplūsma joprojām tiek novirzīta uz citu.
Ražošanas vietnei atjaunošanu uztveriet kā nelielu apkopes izmaiņu ar atgriešanās plānu. Ģenerējiet vai pieprasiet aizstājējsertifikātu, pabeidziet validāciju, instalējiet pilnu sertifikātu ķēdi, atkārtoti ielādējiet attiecīgo tīmekļa pakalpojumu un pārbaudiet, ko patiesībā saņem ār ējie apmeklētāji. Šādi rīkojoties, pakalpojums turpina darboties bez sarežģījumiem, un pārlūkprogrammām nav iemesla brīdināt.
Ko īsti atjauno SSL atjaunošanas process
SSL sertifikāts ir identitātes dokuments, ko serveris uzrāda HTTPS savienojuma laikā. Tas apliecina, ka apmeklētāji ir nonākuši paredzētajā domēnā, un nodrošina šifrētu saziņu starp viņu pārlūkprogrammu un jūsu vietni.
Atjaunošana parasti nenozīmē vietnes, lietotnes vai servera IP adreses maiņu. Tas nozīmē esošā sertifikāta aizstāšanu ar no jauna izdotu sertifikātu, pirms beidzas vecā sertifikāta derīguma termiņš. Publiski uzticamu TLS sertifikātu derīguma termiņš ir ierobežots — bieži vien tas nepārsniedz aptuveni 398 dienas —, un daudzas organizācijas izvēlas īsāku termiņu vai automatizētu izdošanu. Sertifikātā norādītais datums nav pārlūkprogrammas ieteikums. Kad šis datums ir pagājis, apmeklētāji var redzēt brīdinājumu par derīguma termiņa beigām pat tad, ja pati vietne darbojas nevainojami.
Atjaunošanas metode ir atkarīga no sertifikāta veida un izdevēja. Maksas sertifikātam ar organizācijas validāciju var būt nepieciešams apstiprinājums e-pastā, DNS ieraksts vai vietnē ievietots fails. Automatizētiem sertifikātiem parasti izmanto ACME validāciju, izmantojot HTTP vai DNS. Darbības mērķis ir viens un tas pats: pierādīt domēna pārvaldību, saņemt sertifikātu un pareizi to izvietot.
Sāciet ar uzskaiti, nevis paziņojumu par derīguma termiņa beigām
Vispirms jāatrod visi galapunkti, kuros tiek izmantots sertifikāts. Vienam uzņēmumam var būt galvenā vietne, tās www versija, klientu portāls, API, pasta serveris, testēšanas vide un slodzes balansētājs, kuros tiek izmantoti dažādi sertifikāti. Atgādinājums par viena resursdatora nosaukuma derīguma termiņa beigām nenozīmē, ka ir aptverti arī visi pārējie.
Pārbaudiet sertifikāta alternatīvos tēmas nosaukumus, ko parasti sauc par SAN. Tie norāda sertifikātā iekļautos domēnus un apakšdomēnus. Ja `www.example.com` nav iekļauts, sertifikāts tikai domēnam `example.com` to neaizsargās. Aizstājējzīmes sertifikāti aptver pirmā līmeņa apakšdomēnus, piemēram, `shop.example.com`, taču tie automātiski neaptver pamata domēnu vai dziļākus nosaukumus, piemēram, `eu.shop.example.com`.
Noskaidrojiet arī, kur tiek pārtraukta TLS sesija. Vienkāršā VPS vidē sertifikāts var atrasties tieši NGINX, Apache, Caddy vai mitināšanas vadības panelī. Lielākā sistēmā sertifikāts var būt instalēts reversajā starpniekserverī, CDN, mākoņa slodzes balansētājā, Kubernetes ingress kontrollerī vai vairākos mezglos aiz datplūsmas balansētāja. Sertifikāta atjaunošana lietojumprogrammas serverī neko nedod, ja priekšā esošais starpniekserveris joprojām izmanto veco sertifikātu. Dažkārt DNS konfigurācija nav pati sakārtotākā, taču, kartējot datplūsmas ceļu, situāciju var kontrolēt.
Iestatiet iekšējos atgādinājumus agrāk par publiski norādīto derīguma termiņa beigu datumu. Trīsdesmit dienas ir saprātīgs termiņš vienkāršam sertifikātam, savukārt no 45 līdz 60 dienām ir vairāk laika, ja procesā iesaistītas vairākas komandas, ārēji DNS pakalpojumu sniedzēji vai uzņēmuma validācija. Uzraudzības sistēmai jānosūta brīdinājumi vairākos termiņos, piemēram, kad līdz derīguma termiņa beigām atlikušas 30, 14, 7 un 3 dienas. Vienu atgādinājuma e-pastu var filtrēt, ignorēt vai nosūtīt cilvēkam, kurš uzņēmumu pameta pagājušajā pavasarī.
Izvēlieties infrastruktūrai piemērotu validācijas metodi
Domēna pārvaldības validācija ir posms, kurā daudzi atjaunošanas procesi apstājas. Sertifikātu izdevējai iestādei ir nepieciešams pierādījums, ka pārvaldāt pieprasīto domēnu. Labākā ir metode, ko jūsu komanda var droši atkārtot.
HTTP validācijai konkrēts fails jāievieto konkrētā publiskā URL adresē. Tā ir ērta, ja tīmekļa serveris ir tieši sasniedzams 80. portā un apkalpo pareizo virtuālo resursdatoru. Tā var neizdoties, ja datplūsma tiek neparasti novirzīta, vietne atrodas aiz ierobežojoša starpniekservera vai ugunsmūris bloķē validācijas pieprasījumu.
DNS validācijai domēna DNS pakalpojumu sniedzējam jāpievieno TXT ieraksts. Tā bieži ir labāka izvēle aizstājējzīmes sertifikātiem un sistēmām, kurās nav iespējams atklāt HTTP validācijas ceļu. Tā labi darbojas arī sadalītā infrastruktūrā, taču jāparedz laiks DNS izmaiņu izplatīšanai. Dažas DNS izmaiņas stājas spēkā dažu sekunžu laikā, bet citas aizņem ilgāku laiku TTL iestatījumu, pakalpojumu sniedzēja darbības un kešatmiņā saglabāto atrisinātāju dēļ. Nedzēsiet validācijas ierakstu, kamēr nav apstiprināta sertifikāta izdošana.
E-pasta validācija var noderēt nelielā, stabilā vidē, taču tā ir vairāk atkarīga no piekļuves pastkastei un apstiprinātajām adresēm. Ja domēna reģistrācijas kontaktinformācija ir novecojusi vai lomas pastkaste vairs netiek uzraudzīta, atjaunošanas process tur apstājas. Uzņēmumam kritiski svarīgiem pakalpojumiem DNS vai automatizēta ACME validācija parasti samazina atkarību no cilvēku iesaistes.
Ģenerējiet sertifikātu rūpīgi
Manuāli pārvaldītiem sertifikātiem ģenerējiet sertifikāta parakstīšanas pieprasījumu jeb CSR, izmantojot sistēmu, kurā tiks glabāta privātā atslēga. CSR satur publisko atslēgu un domēna informāciju. Privātajai atslēgai jāpaliek privātai. Nesūtiet to pa e-pastu, neievietojiet to atbalsta pieteikumos un neglabājiet koplietotā dokumentā ar nosaukumu `final-final-use-this-one`.
Atjaunošanas laikā varat atkārtoti izmantot esošo atslēgu, taču jaunas privātās atslēgas ģenerēšana parasti ir drošāka izvēle no darbības viedokļa. Atslēgu rotācija ierobežo kaitējumu, ja vecā atslēga ir tikusi atklāta un neviens to nav pamanījis. Kompromiss ir vienkāršs: jauna atslēga rūpīgi jāizvieto visur, kur tiek izmantots sertifikāts. Lielākajā daļā viena servera instalāciju papildu darbs ir minimāls un tā vērts.
Pēc sertifikāta izdošanas lejupielādējiet servera sertifikātu un sertifikātu izdevējas iestādes nodrošināto starpsertifikātu ķēdi. Mūsdienu tīmekļa serveriem bieži ir nepieciešams pilnas ķēdes fails, kurā ir gala sertifikāts un starpsertifikāti. Trūkstoši starpsertifikāti ir biežs pārlūkprogrammu uzticamības kļūdu cēlonis, īpaši vecākās ierīcēs vai mazāk izplatītos klientos.
Automatizēti ACME klienti var apstrādāt atslēgu ģenerēšanu, validāciju, atjaunošanu un instalēšanas āķus. Sertifikātiem, kuriem to var izmantot, ļoti ieteicama automatizācija, taču arī tā ir jāuzrauga. Automātiskās atjaunošanas uzdevums, kas nevar piekļūt DNS, rakstīt sertifikātu direktorijā vai atkārtoti ielādēt NGINX, ir automātisks tikai ļoti optimistiskā nozīmē.
Izvietojiet, nepārtraucot apmeklētāju piekļuvi
Pirms kaut ko aizstājat, nokopējiet pašreizējo sertifikātu un konfigurāciju uz aizsargātu rezerves kopiju glabāšanas vietu. Saglabājiet iepriekšējo sertifikātu, atslēgas atsauci un zināmo labo konfigurāciju pieejamu, līdz jaunā instalācija ir pārbaudīta. Tas nodrošina komandai ātru iespēju atjaunot iepriekšējo stāvokli, ja ķēdes fails, atļauju iestatījums vai sintakses detaļa ir nepareiza.
Instalējiet jauno sertifikātu un tam atbilstošo privāto atslēgu paredzētajā atrašanās vietā. Pārliecinieties, ka tīmekļa servera procesam ir piekļuve failiem, nepadarot privāto atslēgu plaši pieejamu lasīšanai. Linux sistēmā svarīgas ir stingras īpašumtiesības un atļaujas. Sertifikāts pēc būtības ir publisks, bet tā privātā atslēga — ne.
Pirms tīmekļa servera konfigurācijas atkārtotas ielādes pārbaudiet to. NGINX, Apache, HAProxy un līdzīgiem pakalpojumiem vispirms izmantojiet produkta konfigurācijas pārbaudes komandu. Pēc tam, ja iespējams, restartēšanas vietā veiciet atkārtotu ielādi. Atkārtota ielāde piemēro sertifikāta atjauninājumu, vienlaikus ļaujot esošajiem darba procesiem un aktīvajiem savienojumiem korekti pabeigt darbu. Pilna restartēšana apkopes laikā var būt pieņemama, taču daudzās izplatītās konfigurācijās tā nav nepieciešama.
Ja pakalpojums darbojas vairākos serveros, izvietojiet izmaiņas vienādi visos mezglos pirms kontrolētas rotācijas vai tās laikā. Slodzes balansētāji var novirzīt secīgus pārlūkprogrammas pieprasījumus uz dažādām aizmugursistēmām. Ja jaunais sertifikāts ir tikai vienā mezglā, var parādīties periodiski brīdinājumi. Tā ir īpaši kaitinoša problēma, jo šķiet iedomāta, līdz izrādās īsta.
Pārbaudiet no ārpus servera esoša tīkla
Neapstājieties pie tā, ka vadības panelis ziņo par veiksmīgu instalēšanu. Pārbaudiet sertifikātu no ārēja tīkla un apskatiet apmeklētāju izmantoto resursdatora nosaukumu. Pārbaudiet kopīgā nosaukuma vai SAN atbilstību, izdevēju, derīguma termiņa beigu datumu un sertifikātu ķēdi. Pārbaudiet gan pamata domēna, gan www resursdatora nosaukumu, ja abi ir publiski pieejami.
Izmantojiet pārlūkprogrammu kā vienu no pārbaudes veidiem, taču nepaļaujieties tikai uz to. Tā var kešot sesijas vai informāciju par sertifikātu ķēdi. Pārbaudiet ar TLS klientu vai ārēju uzraudzības rīku, kas ziņo par publiskajā IP adresē piedāvāto sertifikātu. Sarežģītākās vidēs katram mitinātajam domēnam, izmantojot servera nosaukuma indikāciju jeb SNI, pārliecinieties, ka tiek atgriezts pareizais sertifikāts.
Pēc tam pārbaudiet lietotnes darbību: piesakieties, iesniedziet veidlapu, izsauciet API galapunktu un pārbaudiet visas trešo pušu atzvanīšanas URL adreses, kurās tiek izmantots HTTPS. Sertifikāta atjaunošana nedrīkst mainīt lietotnes darbību, taču validācijas un starpniekservera noteikumi dažkārt atklāj nesaistītas konfigurācijas problēmas. Tagad žurnāli vēsta to pašu, jo gan ārējā sertifikāta pārbaude, gan lietotnes pārbaudes ir sekmīgas.
Parūpējieties, lai nākamā atjaunošana būtu ikdienišķa
Labākais SSL atjaunošanas process ir tāds, kurā neviens nav spiests steigties. Dokumentējiet sertifikāta īpašnieku, atjaunošanas metodi, DNS pakalpojumu sniedzēju, pakalpojuma atrašanās vietu, skartos resursdatoru nosaukumus un atgriešanās darbības. Glabājiet šo informāciju vietā, kur tai var piekļūt operāciju komanda, nevis tikai viena cilvēka atmiņā.
Pārvaldītiem serveriem sertifikātu uzraudzībai jābūt līdzās darbspējas, diska, dublēšanas un pakalpojumu pārbaudēm. Tuvojošais derīguma termiņa beigu datums ir darbības signāls, nevis tikai administratīvs uzdevums. Vietnē kodu.cloud šāda veida regulāra apkope dabiski iekļaujas pārvaldītā atbalsta un uzraudzības pakalpojumos: laikus identificēt galapunktu, atjaunot sertifikātu ar atbilstošo validācijas metodi un pēc tam pārbaudīt aktīvo pakalpojumu.
Ja sertifikāta derīguma termiņš drīz beigsies, vispirms pārbaudiet, kas pašlaik tiek piedāvāts publiski, un pēc tam secīgi pārbaudiet DNS, validāciju un servera konfigurāciju. Parasti ir iespējams atrast skaidru risinājumu. Atvēliet atjaunošanai pietiekami daudz laika, pārbaudiet to no ārpuses, un apmeklētāji pamanīs tikai to, ka vietne turpina darboties, kā paredzēts.
Andres Saar, klientu atbalsta inženieris