7 SSL sertifikātu atjaunošanas kļūdas, no kurām izvairīties
Publicēts 2026. gada 16. jūlijā
Sertifikātu var veiksmīgi atjaunot un tomēr padarīt jūsu vietni nepieejamu. Tā ir nepatīkamā daļa SSL sertifikātu atjaunošanas kļūdās: paziņojums par atjaunošanu var pazust, kamēr apmeklētāji redz pārlūka brīdinājumu, jo jaunais sertifikāts nekad netika izvietots, neatbilst privātajai atslēgai vai netiek pasniegts no katra galapunkta.
Uztveriet atjaunošanu kā kontrolētas produkcijas izmaiņas, nevis kā kalendāra uzdevumu. Pārbaudiet sertifikātu, validācijas metodi, servera konfigurāciju un publisko rezultātu. Parasti tā ir īsa procedūra. Tomēr, izlaižot vienu nelielu pārbaudi, jūsu komandai var nākties piedzīvot ļoti garu rītu.
1. Derīguma termiņa uzskaite tikai vienas personas kalendārā
Manuāls atgādinājums ir labāks nekā nekāds, taču tas ir trausls risinājums. Cilvēki maina amatus, koplietojamās iesūtnes tiek aizmirstas, un sertifikāts var attiekties uz domēnu, kas vairs nav daļa no ierastā atjaunošanas procesa. Sertifikātiem var būt arī īsāki derīguma termiņi, nekā komandas sagaida, īpaši, ja tie tiek izmantoti vairākos pakalpojumos.
Izmantojiet derīguma termiņa uzraudzību, kas brīdina vairāk nekā vienu atbildīgo personu vai komandu. Noderīgs grafiks ir sākotnējais brīdinājums 30 dienas pirms termiņa beigām, spēcīgāks brīdinājums 14 dienas pirms tam un operatīva eskalācija septiņas dienas pirms tam. Uzņēmējdarbībai kritiskiem domēniem uzraugiet sertifikātu, kas publiski tiek pasniegts 443. portā, nevis tikai portālā reģistrēto derīguma termiņu.
Šai atšķirībai ir nozīme. Jūsu sertifikātu piegādātājs var rādīt derīgu atjaunotu sertifikātu, kamēr internets joprojām saņem veco no slodzes balansētāja, CDN, reversā starpniekservera vai sekundārā servera.
2. Pieņ ēmums, ka automātiska atjaunošana nozīmē arī automātisku izvietošanu
Automātiska atjaunošana ir lieliska, taču tai ir savi ierobežojumi. Daudzi uz ACME balstīti rīki var pieprasīt un lejupielādēt jaunu sertifikātu, to automātiski neinstalējot katrā pakalpojumā, kas izmanto TLS. Nginx, Apache, HAProxy, pasta serveriem, Kubernetes ingress kontrolieriem un lietojumprogrammu starpniekserveriem katram var būt nepieciešama pārlāde, restartēšana vai konfigurācijas atjauninājums.
Pēc atjaunošanas pārbaudiet, uz kuriem failiem pakalpojums patiesībā atsaucas. Bieži sastopama problēma ir tāda, ka atjaunošanas rīks ieraksta jauno sertifikātu vienā direktorijā, kamēr tīmekļa servera konfigurācija joprojām norāda uz vecāku ceļu. Vēl viena ir veiksmīga atjaunošana, kam seko neveiksmīga pārlāde nesaistītas konfigurācijas kļūdas dēļ.
Vienam VPS tas var būt tik vienkārši kā konfigurācijas validēšana un tīmekļa servera saudzīga pārlāde. Lielākā vidē padariet izvietošanu par daļu no atjaunošanas darbplūsmas: atjaunojiet, izplatiet, pārlādējiet un pēc tam testējiet no tīkla ārpuses. Žurnāli tagad stāsta to pašu stāstu tikai tad, kad to apstiprina publiskais galapunkts.
3. Domēna validācijas sabojāšana pirms atjaunošanas dienas
Domēna kontroles validācija ir vieta, kur daudzas atjaunošanas neizdodas. HTTP-01 validācija prasa, lai sertifikācijas iestāde varētu sasniegt konkrētu pārbaudes failu publiskajā tīmeklī. DNS-01 validācija prasa pareizu TXT ierakstu. Abas metodes ir uzticamas, ja apkārtējā infrastruktūra saglabājas stabila.
Problēmas parādās pēc vietnes migrācijas, DNS pakalpojumu sniedzēja maiņas, jauna CDN noteikuma vai drošības politikas, kas bloķē nezināmus ceļus. Pāradresācijas noteikums var nosūtīt validācijas pieprasījumu uz negaidītu vietu. Tīmekļa lietojumprogrammu ugunsmūris to var noraidīt. DNS ieraksti var tikt pārvaldīti vienā kontā, kamēr serveris tiek pārvaldīts citā, kas nav pati skaistākā DNS situācija, taču tā ir pārvaldāma, kad īpašumtiesības ir skaidras.
Pārbaudiet validācijas metodi krietni pirms sertifikāta derīguma termiņa beigām. Ja izmantojat HTTP-01, apstipriniet, ka ceļš `/.well-known/acme-challenge/` ir publiski sasniedzams un to nepārtver lietojumprogramma vai starpniekserveris. Ja izmantojat DNS-01, apstipriniet, ka automatizācijas akreditācijas dati joprojām dod atļauju izveidot vajadzīgos ierakstus un ka jūsu DNS pakalpojumu sniedzēja izplatīšanās laiks atbilst jūsu atjaunošanas logam.
Aizstājējzīmju sertifikātiem jāpievērš īpaša uzmanība. Tiem parasti ir vajadzīga DNS validācija, tāpēc pēdējā brīža atjaunošana var kļūt sarežģīta, ja persona ar piekļuvi DNS nav pieejama.
4. Nepareizā sertifikāta atjaunošana domēniem, kurus jūs faktiski izmantojat
Sertifikāts neaizsargā serveri kopumā. Tas aizsargā precīzi tos nosaukumus, kas uzskaitīti tā Subject Alternative Name jeb SAN laukā. Atjaunojot `example.com`, automātiski netiks aptverts `www.example.com`, `api.example.com`, `shop.example.com` vai klienta apakšdomēns, ko izmanto lietojumprogramma.
Pirms atjaunošanas inventarizējiet katru resursdatora nosaukumu, ko apkalpo sertifikāts. Iekļaujiet pāradresācijas, API, administrēšanas paneļus, uz publisko internetu izliktas sagatavošanas vides un ar pastu saistītus pakalpojumus, ja tie izmanto to pašu sertifikātu. Aģentūrām jāpārbauda arī white-label domēni un klientu domēni, kas gada laikā var būt pievienoti.
Esiet uzmanīgi ar aizstājējzīmju sertifikātiem. Aizstājējzīme, piemēram, `*.example.com`, aptver vienu apakšdomēnu līmeni, piemēram, `app.example.com`. Tā neaptver `api.eu.example.com`, un tā automātiski neiekļauj arī virsotnes domēnu `example.com`. Nepieciešamos nosaukumus pievienojiet skaidri un testējiet tos atsevišķi.
5. Nepareizās privātās atslēgas atkārtota izmantošana vai sertifikātu failu sajaukšana
TLS sertifikāts un tā privātā atslēga ir savstarpēji atbilstošs pāris. Ja jauns sertifikāts tiek instalēts ar vecu, nesaistītu privāto atslēgu, pakalpojumu var neizdoties palaist vai tas var pasniegt nederīgu konfigurāciju. Tas visbiežāk notiek, ja faili tiek manuāli kopēti starp serveriem vai ja vairākiem sertifikātiem ir līdzīgi nosaukumi.
Ir arī sertifikātu ķēde. Pārlūkiem ir vajadzīgs servera sertifikāts un atbilstošie starpsertifikāti. Ja ķēdes fails nav pilnīgs, daži apmeklētāji var redzēt uzticēšanās kļūdas, kamēr citi šķietami netiek ietekmēti kešoto starpsertifikātu vai atšķirīgu ierīču uzticēšanās krātuvju dēļ. Tā nav veiksmīga izvietošana. Tas ir tikai aizkavēts atbalsta pieteikums.
Glabājiet sertifikātu failus paredzamā vietā ar skaidrām atļaujām un īpašumtiesībām. Izmantojiet dokumentētu nosaukumu piešķiršanas konvenciju, īpaši tur, kur vairāki domēni koplieto vienu resursdatoru. Pirms pakalpojuma pārlādes apstipriniet sertifikāta detaļas, atbilstību privātajai atslēgai un pilno ķēdi, ko sagaida jūsu tīmekļa serveris.
6. Viena servera atjaunināšana, kamēr datplūsma sasniedz vairākus
Publiskai vietnei var būt vairāk TLS galapunktu, nekā sagaidīts. Datplūsma var iet caur CDN, mākoņa slodzes balansētāju, atteices pārslēgšanas IP, reverso starpniekserveri, vairākiem lietojumprogrammu mezgliem vai ģeogrāfiski izkliedētiem serveriem. Ja tikai viens galapunkts saņem atjaunoto sertifikātu, lietotājiem problēma var šķist periodiska.
Šī ir viena no SSL sertifikātu atjaunošanas kļūdām, kas rada vislielāko apjukumu. Inženieris pārbauda galveno serveri un redz derīgu sertifikātu. Klients sasniedz citu mezglu un redz brīdinājumu par termiņa beigām. Abi novērojumi var būt patiesi.
Pirms atjaunošanas izkartējiet pilnu pieprasījuma ceļu. Nosakiet, kur beidzas TLS un kuras sistēmas var atbildēt par šo resursdatora nosaukumu. Ja TLS beidzas CDN vai slodzes balansētājā, sertifikāta atjaunošana izcelsmes serverī var nemainīt to, ko saņem apmeklētāji. Ja izcelsmes serveri pieņem arī tiešu datplūsmu, tiem arī ir vajadzīgi derīgi sertifikāti.
Klasterētām sistēmām izvietojiet, izmantojot konfigurācijas pārvaldību vai orķestrētu cauruļvadu, nevis kopējot failus no mezgla uz mezglu. Pēc tam atkārtoti testējiet no ārējiem tīkliem vai uzraudzības vietām. Pārbaude no tā paša privātā tīkla iekšienes ir noderīga, taču tā nepierāda, ka publiskais maršruts ir pareizs.
7. Atjaunošana bez testēšanas, uzraudzības vai atkāpšanās plāna
Atjaunošanas process nav pabeigts, kad komanda atgriež veiksmes ziņojumu. Tas ir pabeigts tad, kad publiska TLS pārbaude apstiprina pareizo resursdatora nosaukumu, derīguma termiņu, sertifikātu ķēdi un galapunkta atbildi.
Testējiet uzreiz pēc izvietošanas. Apstipriniet, ka pakalpojums pasniedz gaidīto sertifikātu, ka ķēde validējas un ka jūsu lietojumprogramma joprojām ir sasniedzama caur HTTPS. E-komercijas, SaaS un pieteikšanās galapunktiem veiciet arī īsu funkcionālo pārbaudi. Derīgs sertifikāts maz palīdz, ja pārlāde atstāja lietojumprogrammu aiz 502 atbildes.
Saglabājiet iepriekšējo zināmi labo sertifikātu un konfigurāciju pieejamu, līdz verifikācija ir pabeigta. Iespējams, atkāpšanās nekad nebūs vajadzīga, taču iespēja ātri atjaunot darbspējīgu stāvokli ir mierīgāka nekā pārveidot izmaiņas zem spiediena. Pierakstiet, kas tika atjaunots, kur tas tika instalēts, kurš to verificēja un kad jānostrādā nākamajam uzraudzības brīdinājumam.
Drošāka atjaunošanas rutīna
Uzticamai rutīnai ir četri posmi: sagatavošanās pirms termiņa beigām, domēna kontroles validācija, izvietošana katrā TLS galapunktā un verifikācija no jūsu infrastruktūras ārpuses. Automatizācija var paveikt lielu daļu šī darba, taču tai joprojām ir vajadzīga uzraudzība un periodiska pārskatīšana pēc DNS, mitināšanas vai lietojumprogrammu izmaiņām.
Ja pārvaldāt pārvaldītu VPS vai vairākas klientu vides, novietojiet sertifikātu derīguma termiņa un izvietošanas pārbaudes līdzās rezerves kopijām, darbspējas laika uzraudzībai un ielāpu uzturēšanai. Tie pieder vienai un tai pašai operacionālajai kategorijai: neliels ikdienas darbs, kas novērš redzamus un dārgus incidentus.
Brīdinājums par sertifikātu ir ļoti labi pamanāms, jo pārlūki ir izstrādāti lietotāju aizsardzībai. Jūsu atjaunošanas procesam jābūt tikpat aizsargājošam: agrīni brīdinājumi, skaidras īpašumtiesības, pārbaudīta automatizācija un cilvēka veikta pārbaude, kad infrastruktūra mainās. Tad pakalpojums paliek mierīgs, un jūsu klienti var turpināt darbu, netiekot iepazīstināti ar aizraujošo sertifikātu kļūdu pasauli.
Andres Saar klientu apkalpošanas inženieris