Kā instalēt SSL VPS serverī bez dīkstāves
Publicēts 2026. gada 9. novembrī
Lai droši instalētu SSL VPS serverī, vispirms pārliecinieties, ka jūsu domēns norāda uz VPS serveri, 80. un 443. ports ir sasniedzams un tīmekļa serveris jau apkalpo pareizo vietni. SSL instalēšana parasti ir ātra. Problēmas gandrīz vienmēr izraisa DNS, ugunsmūra noteikumi vai virtuālā resursdatora konfigurācija, kas norāda uz neparedzētu vietu.
Derīgs sertifikāts šifrē datplūsmu starp apmeklētāju un jūsu lietotni. Tas arī aktivizē pārlūkprogrammas piekaramās atslēgas ikonu, aizsargā pieteikšanās sesijas un maksājumu veidlapas, kā arī novērš brīdinājuma lapu, kuras dēļ klienti aiziet, pirms jūsu vietnei vispār ir iespēja darboties. E-komercijas vietnei, SaaS vadības panelim, aģentūras klienta vietnei vai uzņēmuma e-pasta portālam tā ir ražošanas vides pamata higiēna.
Pirms SSL instalēšanas VPS serverī pārbaudiet šos priekšnoteikumus
Vispirms pārbaudiet DNS ierakstu. Jūsu domēna A ierakstam ir jānorāda uz VPS servera publisko IPv4 adresi. Ja izmantojat IPv6, arī AAAA ierakstam jānorāda uz to pašu serveri. Aizmirsts AAAA ieraksts ir bieži sastopama problēma: daži apmeklētāji nonāk jaunajā serverī, bet citi — vecajā un saņem sertifikāta neatbilstības kļūdu.
Pēc tam pārliecinieties, ka ienākošie TCP porti 80 un 443 ir atvērti abās svarīgajās vietās: VPS ugunsmūrī un pakalpojumu sniedzēja ugunsmūrī. Certbot standarta HTTP validācijai 80. portam jābūt īslaicīgi vai pastāvīgi pieejamam. Tīmekļa serverim šajā portā jāatbild uz pieprasījumiem domēnam.
Pirms jebkādu izmaiņu veikšanas noskaidrojiet arī, kuru tīmekļa serveri un operētājsistēmu izmantojat. Tālāk norādītās komandas paredz, ka izmantojat Ubuntu vai Debian ar Nginx vai Apache. Tie paši sertifikātu principi attiecas uz AlmaLinux, Rocky Linux un citiem distributīviem, taču pakotņu nosaukumi un pakalpojumu komandas var atšķirties.
Vispirms izveidojiet tīmekļa servera konfigurācijas dublējumkopiju. VPS momentuzņēmums vai `/etc/nginx/` vai `/etc/apache2/` dublējumkopija nodrošina tīru atgriešanās punktu. Tas nav nekas dramatisks — vienkārši laba prakse sistēmu pārvaldībā. Nākotnes jūs to novērtēsiet plkst. 2 naktī.
Izvēlieties piemērotāko sertifikāta veidu
Lielākajai daļai vietņu saprātīga izvēle ir bezmaksas Let's Encrypt sertifikāts. Tas nodrošina tādu pašu datu pārraides šifrēšanu kā komerciālie sertifikāti un ir piemērots standarta vietnēm, API un vadības paneļiem. Sertifikāts ir derīgs 90 dienas, tāpēc automātiskā atjaunošana ir instalēšanas daļa, nevis izvēles papildiespēja.
Maksas sertifikāts var būt piemērots, ja jūsu organizācijai nepieciešams noteikts validācijas līmenis, garantijas nosacījumi, konkrēta sertifikātu izdevējiestāde vai pārvaldīts iepirkuma process. Instalēšanas darbības nedaudz atšķiras, jo jāģenerē sertifikāta parakstīšanas pieprasījums, jāsaņem izsniegtie faili un sertifikātu ķēde jāinstalē manuāli.
Ja jūsu lietotne darbojas aiz Cloudflare, slodzes balansētāja vai cita reversā starpniekservera, izlemiet, kur tiks pārtraukta TLS sesija. Iespējams, būs nepieciešams viens sertifikāts starpniekserverī un otrs — starp starpniekserveri un VPS serveri. Nedomājiet, ka oranža mākoņa ikona vai slodzes balansētājs novērš vajadzību šifrēt savienojumu ar sākotnējo serveri. Tas ir atkarīgs no drošības režīma, taču ražošanas vidē parasti pareizā izvēle ir pilnīga šifrēšana no gala līdz galam.
Instalējiet Let's Encrypt sertifikātu ar Certbot
Ubuntu vai Debian sistēmā atjauniniet informāciju par pakotnēm un instalējiet Certbot kopā ar jūsu tīmekļa servera spraudni. Nginx gadījumā izmantojiet:
```bash sudo apt update sudo apt install certbot python3-certbot-nginx ```
Apache gadījumā instalējiet Apache spraudni:
```bash sudo apt update sudo apt install certbot python3-certbot-apache ```
Pirms Certbot palaišanas pārbaudiet tīmekļa servera konfigurāciju. Nginx gadījumā:
```bash sudo nginx -t ```
Apache gadījumā:
```bash sudo apachectl configtest ```
Pirms turpināšanas izlabojiet visas norādītās kļūdas. Sertifikāta pieprasījums var izdoties, bet servera pārlāde var neizdoties — sertifikāts būs diskā, taču apmeklētājiem tas nebūs aktīvs. Žurnālfaili tagad stāsta to pašu, tāpēc izlasiet tos, pirms pievienojat vēl vienu mainīgo elementu.
Nginx vietnei pieprasiet sertifikātu un ļaujiet Certbot atjaunināt servera bloku:
```bash sudo certbot --nginx -d example.com -d www.example.com ```
Apache gadījumā palaidiet:
```bash sudo certbot --apache -d example.com -d www.example.com ```
Aizstājiet `example.com` ar savu faktisko domēnu. Iekļaujiet `www` tikai tad, ja tas ir DNS un konfigurēts tīmekļa serverī. Kad programma uzdod jautājumus, norādiet derīgu e-pasta adresi, piekrītiet noteikumiem un izvēlieties novirzīšanas opciju, ja vēlaties visu HTTP datplūsmu novirzīt uz HTTPS. Vairumā gadījumu novirzīšana ir pareizā izvēle. Tā neļauj apmeklētājiem nokļūt tās pašas lapas nešifrētajā versijā.
Certbot iegūs sertifikātu, pievienos ceļus servera konfigurācijai un pārlādēs attiecīgo pakalpojumu. Esošie HTTP pieprasījumi var tikt apstrādāti kā parasti, un standarta pārlāde parasti nerada ievērojamu dīkstāvi. Tomēr, ja jūsu lietotnei ir sarežģīta starpniekservera konfigurācija vai pielāgoti pārrakstīšanas noteikumi, veiciet šo darbību mazāk noslogotā laikā.
Manuāli instalējiet komerciālu SSL sertifikātu
Ja esat iegādājies sertifikātu, izveidojiet privāto atslēgu un sertifikāta parakstīšanas pieprasījumu VPS serverī. Glabājiet privāto atslēgu serverī un nekad nesūtiet to pa e-pastu vai nepievienojiet atbalsta pieprasījumam.
```bash sudo openssl req -new -newkey rsa:2048 -nodes \ -keyout /etc/ssl/private/example.com.key \ -out /etc/ssl/certs/example.com.csr ```
Sertifikāta nodrošinātājs izsniegs servera sertifikātu un vienu vai vairākus starpsertifikātus. Ja to pieprasa jūsu pakalpojumu sniedzējs, apvienojiet starpsertifikātus pilnā sertifikātu ķēdē. Nginx servera blokā parasti ir nepieciešamas šādas direktīvas:
```nginx listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/ssl/certs/example.com.fullchain.pem; ssl_certificate_key /etc/ssl/private/example.com.key; ```
Apache HTTPS virtuālajā resursdatorā izmanto līdzvērtīgas direktīvas `SSLCertificateFile` un `SSLCertificateKeyFile`. Precīzs failu izvietojums var atšķirties atkarībā no distributīva un vadības paneļa, tāpēc nekopējiet ceļus, tos nepārbaudot. Pārbaudiet arī īpašnieku un atļaujas. Parasti privātajai atslēgai jābūt lasāmai tikai root lietotājam un, ja nepieciešams, pakalpojuma kontam.
Pārbaudiet konfigurāciju un, ja iespējams, restartēšanas vietā pārlādējiet pakalpojumu:
```bash sudo nginx -t && sudo systemctl reload nginx ```
Pārlāde saglabā aktīvos darbplūsmas procesus, vienlaikus piemērojot jauno konfigurāciju. Ja šī iespēja ir pieejama, tā ir mierīgāka izvēle.
Pārbaudiet sertifikātu un novirzīšanas darbību
Privātā pārlūka logā atveriet savu domēnu, izmantojot `https://`. Pārbaudiet, vai parādītais domēns atbilst sertifikātam un pārlūkprogramma norāda, ka savienojums ir drošs. Pēc tam pārbaudiet HTTP versiju un pārliecinieties, ka tā tiek novirzīta uz HTTPS.
VPS serverī vai citā terminālī varat pārbaudīt atbildes galvenes:
```bash curl -I http://example.com curl -I https://example.com ```
HTTP pieprasījumam jāatgriež 301 vai 308 novirzīšana uz HTTPS adresi. HTTPS pieprasījumam jāatgriež sagaidāmais statusa kods, bieži vien 200, 301 vai 302 — atkarībā no jūsu lietotnes.
Pārbaudiet arī pašu sertifikātu:
```bash sudo certbot certificates ```
Komerciāla sertifikāta gadījumā izmantojiet OpenSSL, lai pārbaudītu derīguma termiņu un izdevēja informāciju:
```bash openssl x509 -in /etc/ssl/certs/example.com.fullchain.pem -noout -dates -issuer -subject ```
Neapstājieties pie piekaramās atslēgas ikonas. Jaukts saturs joprojām var ietekmēt lapas, ja skripti, attēli, fonti vai API izsaukumi tiek ielādēti, izmantojot `http://` URL. Pārlūkprogrammas izstrādātāja rīki parādīs šos brīdinājumus. Atjauniniet kodā fiksētās URL adreses, lietotnes vides mainīgos un visus CDN vai resursu iestatījumus.
Uzraugiet sertifikātu atjaunošanu
Let's Encrypt sertifikāti jāatjauno, pirms pagājušas 90 dienas. Mūsdienu Certbot pakotnes parasti automātiski instalē systemd taimeri, tomēr pārbaudiet to, nevis paļaujieties uz klusējošu serveri.
```bash sudo systemctl list-timers | grep certbot sudo certbot renew --dry-run ```
Nozīmīgākais pārbaudījums ir testa režīma palaišana. Tā apstiprina, ka VPS serveris varēs veikt turpmāko validāciju un pēc atjaunošanas pārlādēt tīmekļa serveri. Ja pārbaude neizdodas, novērsiet problēmu, kamēr esošais sertifikāts vēl ir derīgs.
Komerciāliem sertifikātiem krietni iepriekš kalendārā atzīmējiet derīguma termiņa beigu datumu. Atjaunošana bieži jāveic manuāli, ja vien sertifikāta nodrošinātājs vai pārvaldības platforma neatbalsta automatizāciju. Ja iespējams, pievienojiet sertifikāta derīguma termiņa uzraudzību. Derīgs sertifikāts, kura termiņš beidzas nepamanīts, joprojām izraisa darbības pārtraukumu — tikai ar ļoti oficiāla izskata pārlūkprogrammas kļūdas paziņojumu.
Vietnē kodu.cloud pārvaldīts operatīvais atbalsts un uzraudzība var mazināt šāda veida atkārtotu risku, jo īpaši tad, ja VPS serverī tiek mitināti vairāki klientu domēni vai ražošanas pakalpojumi. Mērķis ir vienkāršs: sertifikātiem jāatjaunojas nemanāmi, un jūsu komandai nevajadzētu par tiem atcerēties katru ceturksni.
Biežākās problēmas pēc SSL instalēšanas
Sertifikāta neatbilstība parasti nozīmē, ka pieprasījums sasniedz nepareizo VPS serveri, kā noklusējuma serveris darbojas nepareizais virtuālais resursdators vai sertifikāta pieprasījumā nav iekļauts resursdatora nosaukums, piemēram, `www`. Vispirms pārbaudiet DNS, pēc tam — tīmekļa serverī konfigurētos serveru nosaukumus.
Validācijas kļūme parasti norāda uz 80. portu, DNS izmaiņu izplatīšanos vai starpniekservera konfigurāciju. Ja domēns izmanto CDN, pārliecinieties, ka tā DNS ieraksti un starpniekservera režīms atbalsta izvēlēto validācijas metodi. DNS izaicinājuma validācija bieži ir piemērotāka aizstājējzīmju sertifikātiem, taču tai nepieciešama piekļuve DNS API vai manuāla DNS ieraksta izveide.
Ja pēc HTTPS piespiedu aktivizēšanas vietne tiek novirzīta ciklā, pārbaudiet, vai novirzīšana vienlaikus nav konfigurēta lietotnē, Nginx vai Apache, kā arī reversajā starpniekserverī. Lietotnēm, kas darbojas aiz starpniekservera, var būt nepieciešams uzticams pārsūtīto galveņu iestatījums, lai tās atpazītu sākotnējo pieprasījumu kā HTTPS pieprasījumu. Šāda DNS situācija nav īpaši glīta, taču to var kontrolēt, tiklīdz ir skaidri noteikts viens atbildīgais par novirzīšanu.
Iekļaujiet sertifikātu, tīmekļa servera konfigurāciju un atjaunošanas pārbaudes vienā un tajā pašā operatīvajā rutīnā. Pareizi instalētam SSL sertifikātam jākļūst par garlaicīgu infrastruktūras daļu — tam jābūt pieejamam un pārbaudītam, neprasot īpašu uzmanību.
Andres Saar, klientu atbalsta inženieris