Usaldusväärne SSL-sertifikaadi uuendamine ilma katkestuseta
Avaldatud 18. oktoobril 2026
SSL-sertifikaadi uuendamist tuleks alustada aegsasti enne sertifikaadi aegumist ning eelnevalt peaksid olema kontrollitud sertifikaatide loend, DNS-i juurdepääs ja juurutamise viis. Sertifikaadi uuendamine on tavaliselt rutiinne toiming. Katkestused tekivad sellega seoses: unustatud alamdomeen, valesse DNS-tsooni lisatud valideerimiskirje või ühte serverisse paigaldatud uus sertifikaat, samal ajal kui liiklus jõuab endiselt teise serverisse.
Tootmiskeskkonna veebisaidi puhul käsitle uuendamist väikese hooldusmuudatusena, mille jaoks on tagasipööramisplaan olemas. Genereeri või taotle asendussertifikaat, vii valideerimine lõpule, paigalda kogu sertifikaadiahel, laadi vastav veebiteenus uuesti ja kontrolli, mida väliskülastajad tegelikult saavad. Nii toimides töötab teenus häireteta ja brauseritel pole põhjust tõrkeid kuvada.
Mida SSL-sertifikaadi uuendamisel tegelikult uuendatakse
SSL-sertifikaat on isikut tõendav dokument, mille sinu server HTTPS-ühenduse loomisel esitab. See kinnitab, et külastajad jõudsid õigesse domeeni, ja loob krüpteeritud ühenduse nende brauseri ja sinu saidi vahel.
Uuendamine ei tähenda tavaliselt veebisaidi, rakenduse ega serveri IP-aadressi muutmist. See tähendab olemasoleva sertifikaadi asendamist uue väljastatud sertifikaadiga enne vana aegumist. Avalikult usaldatud TLS-sertifikaatide kehtivusaeg on piiratud, sageli kuni umbes 398 päevaga, ning paljud organisatsioonid valivad lühema kehtivusaja või automatiseeritud väljastamise. Sertifikaadil märgitud kuupäev ei ole brauseri soovitus. Pärast selle möödumist võidakse külastajatele kuvada aegumishoiatus isegi siis, kui sait ise töötab täiesti korralikult.
Uuendamise meetod sõltub sertifikaadi tüübist ja väljastajast. Tasuline organisatsiooni valideerimisega sertifikaat võib nõuda kinnitust e-kirja, DNS-kirje või veebisaidile paigutatud faili kaudu. Automatiseeritud sertifikaatide puhul kasutatakse tavaliselt ACME valideerimist HTTP või DNS-i kaudu. Eesmärk on sama: tõendada domeeni üle kontrolli omamist, saada sertifikaat ja juurutada see õigesti.
Alusta inventuurist, mitte aegumisteavitusest
Kõigepealt tuleb leida kõik lõpp-punktid, mis sertifikaati kasutavad. Ühel ettevõttel võivad olla põhisait, www-versioon, kliendiportaal, API, meiliserver, testkeskkond ja koormusjaotur, mis kasutavad erinevaid sertifikaate. Ühe hostinime aegumismeeldetuletus ei tõenda, et kõik teised on kaetud.
Kontrolli sertifikaadi subjekti alternatiivseid nimesid, mida tavaliselt nimetatakse SAN-ideks. Need näitavad sertifikaadiga hõlmatud domeene ja alamdomeene. Kui `www.example.com` ei ole kaasatud, ei kaitse ainult domeeni `example.com` sertifikaat seda. Metamärgisertifikaadid katavad esimese taseme alamdomeene, näiteks `shop.example.com`, kuid ei kata automaatselt juurdomeeni ega sügavamaid nimesid, näiteks `eu.shop.example.com`.
Tuvasta ka koht, kus TLS-i lõpetamine toimub. Lihtsa VPS-i puhul võib sertifikaat asuda otse NGINX-is, Apache'is, Caddys või majutuse juhtpaneelis. Suuremas keskkonnas võib sertifikaat olla paigaldatud pöördpuhverserverisse, CDN-i, pilve koormusjaoturisse, Kubernetes Ingressi kontrollerisse või mitmesse liiklusjaoturi taga asuvasse sõlme. Sertifikaadi uuendamisest rakendusserveris pole kasu, kui ees olev puhverserver esitab endiselt vana sertifikaati. DNS-i olukord pole mõnikord kõige ilusam, kuid kui liikluse teekond on kaardistatud, on see kontrolli all.
Määra sisemised meeldetuletused avalikust aegumiskuupäevast varasemaks. Lihtsa sertifikaadi puhul on kolmkümmend päeva mõistlik, samas kui mitme meeskonna, väliste DNS-i pakkujate või ettevõtte valideerimise korral annab 45–60 päeva rohkem tegutsemisruumi. Seire peaks andma häire rohkem kui ühes etapis, näiteks siis, kui kehtivusaega on järel 30, 14, 7 ja 3 päeva. Üks meeldetuletuskiri võib sattuda rämpsposti, jääda märkamata või jõuda inimeseni, kes lahkus ettevõttest juba eelmisel kevadel.
Vali taristule sobiv valideerimismeetod
Domeeni kontrolli valideerimine on etapp, kus paljud uuendamised takerduvad. Sertifikaadiasutus vajab tõendit selle kohta, et kontrollid taotletud domeeni. Parim meetod on see, mida sinu meeskond suudab ohutult korrata.
HTTP valideerimise korral paigutatakse kindel fail kindlale avalikule URL-ile. See on mugav, kui veebiserver on pordil 80 otse kättesaadav ja väljastab õige virtuaalserveri sisu. See võib ebaõnnestuda, kui liiklus suunatakse ebatavalisel viisil ümber, sait asub piirava puhverserveri taga või tulemüür blokeerib valideerimispäringu.
DNS-i valideerimiseks tuleb domeeni DNS-i pakkuja juures lisada TXT-kirje. See on sageli parem valik metamärgisertifikaatide ja süsteemide puhul, mis ei saa HTTP valideerimise teed avalikustada. See sobib hästi ka hajutatud taristu jaoks, kuid DNS-i levikuks tuleb aega varuda. Mõned DNS-i muudatused jõustuvad sekunditega, teised võtavad TTL-i sätete, pakkuja käitumise ja vahemällu salvestavate nimeresolverite tõttu kauem aega. Ära eemalda valideerimiskirjet enne, kui sertifikaadi väljastamine on kinnitatud.
E-posti teel valideerimine võib sobida väikeses ja stabiilses keskkonnas, kuid see sõltub rohkem postkasti juurdepääsust ja heakskiidetud aadressidest. Kui domeeni registreerimisel märgitud kontaktandmed on aegunud või rollipostkasti enam ei jälgita, jääb uuendamine sinna toppama. Ärikriitiliste teenuste puhul tekitab DNS-i või automatiseeritud ACME valideerimine tavaliselt vähem inimtekkelisi kitsaskohti.
Genereeri sertifikaat hoolikalt
Käsitsi hallatavate sertifikaatide puhul genereeri sertifikaadiallkirja päring ehk CSR süsteemis, kuhu salvestatakse privaatvõti. CSR sisaldab avalikku võtit ja domeeni üksikasju. Privaatvõti peab jääma privaatseks. Ära saada seda e-postiga, kleebi piletitesse ega hoia jagatud dokumendis nimega `final-final-use-this-one`.
Uuendamisel võib olemasolevat võtit uuesti kasutada, kuid uue privaatvõtme genereerimine on üldiselt töökorralduslikult turvalisem valik. Võtme vahetamine piirab kahju, kui vana võti lekkis nii, et keegi seda ei märganud. Kompromiss on lihtne: uus võti tuleb hoolikalt juurutada kõikjal, kus sertifikaati kasutatakse. Enamiku ühe serveriga paigaldiste puhul on lisatöö väike ja end ära tasuv.
Pärast sertifikaadi väljastamist laadi alla serveri sertifikaat ja sertifikaadiasutuse pakutav vahesertifikaatide ahel. Tänapäevased veebiserverid vajavad sageli täielikku ahelat sisaldavat faili, milles on lõppsertifikaat ja vahesertifikaadid. Puuduvad vahesertifikaadid põhjustavad sageli brauseri usaldusvigu, eriti vanemates seadmetes või vähem levinud klientides.
Automatiseeritud ACME-kliendid saavad hallata võtmete genereerimist, valideerimist, uuendamist ja paigalduskonkse. Võimaluse korral on sertifikaatide automatiseerimine tungivalt soovitatav, kuid seda tuleb siiski seirata. Automaatne uuendustoiming, mis ei pääse DNS-ile ligi, ei saa sertifikaatide kataloogi kirjutada või NGINX-it uuesti laadida, on automaatne vaid väga optimistlikus tähenduses.
Juuruta külastajaid katkestamata
Enne millegi asendamist kopeeri praegune sertifikaat ja konfiguratsioon kaitstud varukoopiate asukohta. Hoia eelmine sertifikaat, võtme viide ja teadaolevalt toimiv konfiguratsioon käepärast, kuni uue paigalduse toimimine on kontrollitud. Nii saab sinu meeskond kiiresti eelmisele versioonile tagasi minna, kui ahelafaili, õiguste sätte või süntaksiga on midagi valesti.
Paigalda uus sertifikaat ja sellele vastav privaatvõti ettenähtud asukohta. Veendu, et veebiserveri protsess saab faile lugeda, muutmata privaatvõtit laialdaselt loetavaks. Linuxis on piiratud omandiõigus ja juurdepääsuõigused olulised. Sertifikaat ongi mõeldud avalikuks kasutamiseks, privaatvõti aga mitte.
Valideeri veebiserveri konfiguratsioon enne selle uuesti laadimist. NGINX-i, Apache'i, HAProxy ja sarnaste teenuste puhul kasuta kõigepealt toote konfiguratsiooni testimise käsku. Seejärel laadi teenus võimaluse korral uuesti, selle asemel et see taaskäivitada. Uuesti laadimisel rakendatakse sertifikaadi uuendus ning olemasolevatel töötlejaprotsessidel ja aktiivsetel ühendustel lastakse korrektselt lõpule jõuda. Täielik taaskäivitamine võib hooldusaknas sobida, kuid paljudes tavapärastes seadistustes pole see vajalik.
Kui teenus töötab mitmes serveris, juuruta sertifikaat järjepidevalt kõigis sõlmedes enne kontrollitud vahetust või selle ajal. Koormusjaoturid võivad suunata järjestikused brauseripäringud eri taustaserveritesse. Kui uus sertifikaat on ainult ühes sõlmes, võivad ilmneda juhuslikud hoiatused. See on eriti tüütu probleem, sest tundub väljamõeldisena, kuni seda enam pole.
Kontrolli serverist väljastpoolt
Ära lõpeta kontrollimist pärast seda, kui juhtpaneel teatab paigalduse õnnestumisest. Kontrolli sertifikaati välisvõrgust ja vaata üle hostinimi, mida külastajad kasutavad. Kinnita üldnime või SAN-ide hõlmatus, väljastaja, aegumiskuupäev ja sertifikaadiahel. Kontrolli nii juurdomeeni kui ka www-hostinime, kui mõlemad on avalikud.
Kasuta ühe kontrollimise viisina brauserit, kuid ära looda ainult sellele. Brauser võib seansse või ahelateavet vahemällu salvestada. Testi TLS-kliendi või välise seirekontrolliga, mis näitab avalikul IP-aadressil esitatavat sertifikaati. Keerukamates keskkondades kontrolli iga majutatud domeeni puhul Server Name Indicationi ehk SNI abil, et tagastatakse õige sertifikaat.
Seejärel kontrolli rakenduse toimimist: logi sisse, saada vorm, kutsu API lõpp-punkti ja kontrolli kõiki HTTPS-i kasutavaid kolmanda osapoole tagasihelistamise URL-e. Sertifikaadi uuendamine ei tohiks rakenduse käitumist muuta, kuid valideerimis- ja puhverserveri reeglid võivad mõnikord esile tuua seosetuid konfiguratsiooniprobleeme. Nüüd räägivad logid sama keelt, sest nii väline sertifikaadikontroll kui ka rakenduse kontrollid õnnestuvad.
Muuda järgmine uuendamine igavaks
Parim SSL-sertifikaadi uuendamise protsess on selline, millega kellelgi pole kiiret. Dokumenteeri sertifikaadi omanik, uuendamismeetod, DNS-i pakkuja, teenuse asukoht, mõjutatud hostinimed ja tagasipööramise etapid. Salvesta see teave kohta, kus tegevusmeeskond sellele ligi pääseb, mitte ainult ühe inimese mällu.
Hallatavate serverite puhul peaks sertifikaatide seire käima koos tööaja, ketta, varunduse ja teenuse kontrollidega. Lähenev aegumiskuupäev on töökorralduslik signaal, mitte pelgalt haldusülesanne. Kodu.cloudis sobib selline korduv hooldus loomulikult kokku hallatud toe ja seirega: tuvasta lõpp-punkt aegsasti, uuenda sobiva valideerimismeetodiga ja kontrolli seejärel töötavat teenust.
Kui sertifikaat hakkab juba aeguma, kontrolli esmalt, mida avalikkusele praegu esitatakse, ja liigu seejärel sissepoole, uurides DNS-i, valideerimist ja serveri konfiguratsiooni. Edasi liikumiseks on tavaliselt selge tee. Jäta uuendamiseks piisavalt aega, kontrolli seda väljastpoolt ning külastajad märkavad vaid seda, et sait töötab edasi nii, nagu peab.
Andres Saar, klienditoe insener