Kā pareizi iestatīt SSL sertifikātus
Publicēts 2026. gada 3. jūnijā
Darbojošs SSL iestatījums nav tikai “instalē sertifikātu, un viss.” Sertifikātam ir jāatbilst domēnam, privātajai atslēgai jāpaliek pareizajā serverī, DNS ir jānorāda tur, kur, jūsuprāt, tas norāda, un jūsu tīmekļa serverim ir jāuzrāda pareizais sertifikāts pareizajam resursdatorvārdam. Ja meklējat, kā iestatīt SSL sertifikātus bez pārsteigumiem plkst. 2 naktī, šis ir praktiskais ceļš.
Kā iestatīt SSL sertifikātus bez minējumiem
Sāciet ar vienu jautājumu: ko tieši jūs aizsargājat? Vienam domēnam, piemēram, example.com, ir nepieciešams cits sertifikāta tvērums nekā iestatījumam ar www.example.com, app.example.com un shop.example.com. Ja sākumā izvēlaties nepareizu sertifikāta tipu, var nākties to izsniegt no jauna piecas minūtes vēlāk, kas nav traģiski, bet arī nav eleganti.
Lielākajai daļai uzņēmumu ir trīs izplatītas iespējas. Viena domēna sertifikāts aptver vienu resursdatorvārdu. Aizstājējzīmes sertifikāts aptver apakšdomēnus, piemēram, anything.example.com, bet ne vienmēr saknes domēnu, ja vien tas nav īpaši iekļauts. Vairāku domēnu jeb SAN sertifikāts aptver vairākus nosauktus resursdatorvārdus. Pareizā izvēle ir atkarīga no jūsu faktiskā datplūsmas modeļa, nevis no tā, kas izklausās sarežģītāk.
Nākamā pārbaude ir īpašumtiesību validācija. Sertifikācijas iestādēm ir nepieciešams pierādījums, ka jūs kontrolējat domēnu. Tas parasti notiek, izmantojot HTTP validāciju, DNS validāciju vai dažreiz e-pasta validāciju. HTTP bieži ir visātrākais, ja vietne serverī jau ir sasniedzama. DNS ir uzticamāks aizstājējzīmēm un vidēm aiz starpniekserveriem, slodzes balansētājiem vai izstrādes vides noteikumiem, kas padara tīmekļa validāciju juceklīgu. Dažreiz tā nav pati skaistākā DNS situācija, taču tā ir kontrolējama, ja zināt, kura metode atbilst iestatījumam.
Sagatavojiet serveri, pirms kaut ko instalējat
Pirms ģenerējat CSR vai noklikšķināt uz automātiskās instalēšanas pogas, pārbaudiet četras lietas. Domēnam ir jāatrisinās uz pareizo publisko IP. Ugunsmūrī ir jābūt atvērtiem 80. un 443. portam. Tīmekļa serverim jau ir jāzina, kurš virtuālais resursdators vai servera bloks atbildēs par šo domēnu. Un servera sistēmas laikam ir jābūt pareizam, jo SSL un nepareizam laikam ir sena nesaskaņu vēsture.
Ja izmantojat Nginx vai Apache, vispirms pārbaudiet esošo vietnes konfigurāciju. Sertifikāts var būt pilnīgi derīgs un tomēr pārlūkā nedarboties, ja tīmekļa serveris nosūta noklusējuma sertifikātu no citas vietnes tajā pašā mašīnā. Tas ir īpaši bieži VPS mezglos, kuros tiek mitināti vairāki domēni. SNI to atrisina, bet tikai tad, ja vhost kartēšana ir pareiza.
Jums arī jāizlemj, vai vēlaties manuālu sertifikātu pārvaldību vai automatizētu atjaunošanu. Manuāla pieeja var būt pieņemama vienai videi ar retām izmaiņām, taču tā rada operacionālu risku. Lielākā daļa komandu atjaunošanas neaizmirst tīšām. Tās aizmirst, jo ir aizņemtas ar ieņēmumus nesošu darbu, nevis ar derīguma termiņu uzraudzīšanu.
Pareizi ģenerējiet sertifikāta pieprasījumu
Ja jūsu vadības panelis to apstrādā, izmantojiet to. Ja ne, ģenerējiet privāto atslēgu un CSR tajā serverī, kur sertifikāts atradīsies. Privāto atslēgu nevajadzētu sūtīt pa e-pastu, ievietot koplietotā čatā vai kopēt uz nejaušiem klēpjdatoriem. Žurnāli katru reizi stāsta vienu un to pašu - attieksme pret atslēgu apstrādi kļūst pārāk pavirša tieši pirms kādam sākas slikta nedēļa.
CSR ir jāiekļauj pareizais vispārīgais nosaukums un visi nepieciešamie subjekta alternatīvie nosaukumi. Mūsdienu pārlūkiem SAN ieraksti ir svarīgāki par veco vispārīgā nosaukuma lauku. Ja jums vajag gan example.com, gan www.example.com, pārliecinieties, ka abi ir iekļauti. Viena resursdatorvārda neiekļaušana ir klasisks avots apjukumam “man tas darbojas, klientiem ne”.
Automatizētai izsniegšanai šo soli jūsu vietā apstrādā tādi rīki kā ACME klienti. Tie var ģenerēt atslēgas, pabeigt validāciju, instalēt sertifikātus un ieplānot atjaunošanu. Daudzām VPS un pārvaldīta hostinga vidēm tas ir tīrākais ceļš, īpaši tur, kur darbspējas laiks un atkārtojamība ir svarīgāki par manuālu ceremoniju.
Instalējiet SSL sertifikātu savā tīmekļa serverī
Kad sertifikāts ir izsniegts, instalējiet sertifikāta failu kopā ar jebkuru nepieciešamo starpsertifikātu pakotni un atbilstošo privāto atslēgu. Precīzie failu ceļi un direktīvas ir atkarīgi no tīmekļa servera.
Nginx gadījumā sertifikātu un atslēgu definē servera blokā 443. portam. Apache gadījumā konfigurējat sertifikāta failu, atslēgas failu un ķēdi attiecīgajā VirtualHost. Ja izmantojat vadības paneli, panelis var ievietot šīs vērtības jūsu vietā un automātiski pārbūvēt konfigurāciju.
Pēc instalēšanas eleganti pārlādējiet tīmekļa serveri, nevis veiciet pilnu restartēšanu, ja vien tam nav iemesla. Pārlāde piemēro jauno sertifikātu, vienlaikus samazinot traucējumus. Pēc tam pārbaudiet, ko serveris patiesībā uzrāda, nevis to, ko, jūsuprāt, tam vajadzētu uzrādīt. Pārlūki agresīvi kešo, un reversie starpniekserveri var slēpt kļūdas ilgāk, nekā būtu veselīgi.
Piespiediet HTTPS uzmanīgi, nevis akli
Kad sertifikāts ir aktīvs, novirziet HTTP datplūsmu uz HTTPS. Tas ir standarts, taču svarīgs ir laiks. Nespiediet HTTPS pirms sertifikāts ir derīgs un tiek pareizi pasniegts, citādi izveidosiet ātru ceļu uz pārlūka brīdinājumiem.
Iestatiet 301 novirzīšanu no HTTP uz HTTPS vai nu tīmekļa servera līmenī, vai lietojumprogrammas slānī, taču izvairieties no abu sakraušanas, ja vien tam nav iemesla. Pārāk daudz novirzīšanas noteikumu rada cilpas, jauktus resursdatorvārdus vai darbību, kas atšķiras starp vidēm. Saglabājiet to vienkāršu.
Ja vietne izmanto resursus no veciem HTTP URL, atjauniniet tos. Jaukta satura brīdinājumi rodas, kad lapa ielādējas caur HTTPS, bet skriptus, attēlus, fontus vai stilu lapas ielādē caur HTTP. Sertifikāts var būt perfekts, bet piekaramā atslēga joprojām izskatās nelaimīga. Īpaši e-komercijas norēķinu lapas un SaaS informācijas paneļi jāpārbauda lappusi pa lappusei, nevis tikai sākumlapa.
Pārbaudiet iestatījumu kā cilvēks, kurš neuzticas veiksmei
Atveriet vietni pārlūkā un pārbaudiet sertifikāta detaļas. Apstipriniet, ka resursdatorvārds atbilst, derīguma datumi ir pareizi un tiek uzrādīta pilnā ķēde. Pēc tam, ja iespējams, pārbaudiet no komandrindas. Jūs vēlaties precīzi redzēt, kuru sertifikātu serveris atgriež pieprasītajam resursdatorvārdam.
Pēc instalēšanas pārbaudiet šos praktiskos punktus:
- Gan saknes domēns, gan www versija darbojas, kā paredzēts
- Sertifikātu ķēde ir pilnīga
- HTTP novirza uz HTTPS vienu reizi, nevis trīs
- Tīmekļa serveris katram resursdatorvārdam pasniedz paredzēto sertifikātu
- Atjaunošana ir konfigurēta un tiešām ieplānota
Ja izmantojat CDN vai reverso starpniekserveri, pārliecinieties, ka sertifikāts atrodas pareizajā vietā. Daži iestatījumi pārtrauc SSL pie starpniekservera un pēc tam sūta vienkāršu HTTP uz izcelsmes serveri. Citi izmanto pilnīgu šifrēšanu ar sertifikātiem gan starpniekserverī, gan izcelsmes serverī. Neviena no šīm pieejām nav universāli pareiza vai nepareiza. Tas ir atkarīgs no jūsu drošības modeļa, uzticēšanās iekšējam tīklam un lietojumprogrammas vajadzībām.
Izplatītas SSL problēmas un to parastā nozīme
Pārlūka brīdinājums par resursdatorvārda neatbilstību parasti nozīmē, ka tiek pasniegts nepareizais sertifikāts, bieži tāpēc, ka pieprasījumu uztver noklusējuma vhost. Brīdinājums par “nepilnīgu ķēdi” nozīmē, ka trūkst starpsertifikātu. Sertifikāts, kuram beidzies derīguma termiņš, ir acīmredzams, lai gan joprojām kaut kā populārs. Validācijas kļūmes bieži norāda uz DNS ierakstiem, kas neatbilst paredzētajam serverim, kešošanu DNS slānī vai ugunsmūri, kas bloķē HTTP izaicinājuma pieprasījumus.
Atjaunošanas kļūmēm jāpievērš īpaša uzmanība. Ja paļaujaties uz automatizētu SSL un vēlāk maināt DNS, pievienojat starpniekserveri vai pastiprināt ugunsmūra noteikumus, atjaunošanas ceļš var klusi salūzt. Pirmā instalēšana izdevās, visi atslāba, un sešdesmit dienas vēlāk problēma atgriežas nepiemērotā brīdī. Tāpēc sertifikātu derīguma termiņa uzraudzība ražošanas vidē nav izvēles iespēja. Tā ir pamata operacionālā higiēna.
Pārvaldīta vai pašpārvaldīta SSL iestatīšana
Ja uzturat savu steku paši, manuāla SSL iestatīšana sniedz pilnīgu kontroli. Jūs izvēlaties validācijas metodi, atslēgu glabāšanu, šifru politiku, novirzīšanas darbību un izvietošanas procesu. Tas ir noderīgi pielāgotām infrastruktūrām, klasterētiem pakalpojumiem vai vidēm ar stingrām atbilstības prasībām.
Komplekts ir operacionālā atbildība. Kādam ir jāuzrauga atjaunošanas, jāapstiprina veiksmīga atkārtota izsniegšana un jāfiksē izmaiņas, kas salauž validāciju. Mazām komandām, aģentūrām un dibinātājiem, kuri jau tāpat pilda piecas lomas, pārvaldīts hostings ar SSL automatizāciju bieži ir mierīgāka izvēle. Laba platforma noņem atkārtotu darbu, vienlaikus neslēpjot pamatā esošo servera darbību. At kodu.cloud tas parasti arī ir galvenais — mazāk stresa, bet joprojām pietiekama kontrole.
Kā iestatīt SSL sertifikātus ilgtermiņa stabilitātei
Instalēšana ir tikai pirmais solis. Stabils iestatījums ietver automātisku atjaunošanu, derīguma termiņa uzraudzību, skaidras vhost kartēšanas un ieradumu atkārtoti pārbaudīt SSL pēc DNS vai starpniekservera izmaiņām. Ja vietne ir kritiski svarīga biznesam, izturieties pret sertifikāta statusu tāpat kā pret dublējumiem un darbspējas laika brīdinājumiem. Klusas sistēmas ir labas sistēmas.
Sargājiet savas privātās atslēgas, padariet atjaunošanas procesu automātisku, kur vien iespējams, un saskaņojiet validācijas metodi ar to, kā datplūsma patiešām sasniedz jūsu serveri. Ja pēc tam pakalpojums atkal ir mierīgs, jūs to izdarījāt pareizi.
Andres Saar Klientu apkalpošanas inženieris