Kā uzinstalēt SSL sertifikātu
SSL/TLS sertifikāta uzstādīšana ir process, kurā jūs pievienojat sertifikātu un privāto atslēgu serverim, konfigurējat web serveri (piemēram, Nginx vai Apache), un nodrošināt, ka vietne ir pieejama ar HTTPS bez brīdinājumiem. Praktiski “uzinstalēt SSL” nozīmē trīs lietas: iegūt sertifikātu (vai ģenerēt to ar Let’s Encrypt), pareizi uzlikt sertifikāta ķēdi (intermediate/CA bundle), un pieslēgt sertifikātu konkrētajam domēnam virtual host konfigurācijā. Ja kaut viena no šīm daļām ir nepareiza, pārlūks var rādīt kļūdas, vai arī HTTPS darbosies tikai daļēji.
Pirms sākat, pārliecinieties, ka domēns jau rāda uz jūsu serveri un ka DNS ir korekts. Ja jūs maināt infrastruktūru, visdrošāk ir vispirms sagatavot HTTPS jaunajā vidē, un tikai tad pārslēgt DNS. Ja jums ir pārvaldīta vide, uzstādīšana parasti notiek ātrāk un ir automatizēta; ja jums ir pilna kontrole pār serveri, jūs varēsiet smalkāk pielāgot drošības parametrus, bet būs jāseko līdzi atjaunošanai un konfigurācijai.
CloudHosting pusē SSL risinājumus var izvēlēties atbilstoši vajadzībām: ja jums vajag konkrētu sertifikāta tipu (DV/OV/EV, wildcard vai multi-domain), skatiet pakalpojumu lapu SSL sertifikāti. Ja jūs gribat vienkāršu risinājumu vietnei bez servera administrēšanas, bieži pietiek ar hostingu. Ja jums nepieciešama pilna kontrole, pielāgoti porti, reverse proxy vai vairākas aplikācijas, parasti izvēlas virtuālos serverus.
1) Izvēlieties sertifikāta veidu un iegūšanas metodi
Ir divi izplatītākie ceļi. Pirmais: izmantot Let’s Encrypt un ACME klientu (piemēram, certbot), kas automatizē gan izsniegšanu, gan atjaunošanu. Otrs: iegādāties sertifikātu pie sertifikācijas iestādes (CA) vai izmantot DV/OV/EV sertifikātu, kas tiek izsniegts pēc validācijas, un pēc tam manuāli to uzstādīt serverī. Abos gadījumos serverim vajadzēs privāto atslēgu un sertifikāta failus, taču Let’s Encrypt gadījumā tos parasti izveido un pārvalda ACME klients.
Ja jums ir viens domēns un pāris apakšdomēni, parasti pietiek ar DV sertifikātu. Ja jums ir daudz apakšdomēnu vienā domēnā, apsveriet wildcard sertifikātu, un tad bieži būs vajadzīga DNS-01 validācija (TXT ieraksts DNS zonā). Ja jums ir vairāk nekā viens domēns vienā projektā, noder SAN (multi-domain) sertifikāts. Izvēlei ir jēga, jo tā ietekmē gan uzstādīšanas procesu, gan turpmāko uzturēšanu.
2) Sagatavojiet serveri: porti, virtuālie hosti, ugunsmūris
HTTPS parasti izmanto TCP portu 443. Pārliecinieties, ka 443 ir atvērts ugunsmūrī un ka serveris klausās uz pareizās IP adreses. Ja izmantojat Let’s Encrypt HTTP-01 validāciju, uz brīdi (vai pastāvīgi) ir jābūt pieejamam arī portam 80, jo CA pārbauda īpašu failu mapē /.well-known/acme-challenge/. Ja jums portu 80 atvērt nedrīkst, tad izmanto DNS-01 validāciju, publicējot TXT ierakstu DNS zonā.
Ja uz viena IP dzīvo vairāki domēni, mūsdienās gandrīz vienmēr strādā SNI (Server Name Indication), kas ļauj vienam serverim atdot dažādus sertifikātus atkarībā no pieprasītā domēna. Tomēr ļoti vecām ierīcēm bez SNI var rasties “nepareiza sertifikāta” situācija. Ja jums ir šāds mantojums, reizēm risinājums ir atsevišķa IP adrese kritiskajam domēnam, vai arī saderības režīma izvēle.
3) Ja lietojat Let’s Encrypt: tipisks uzstādīšanas scenārijs
Let’s Encrypt uzstādīšanas ideja ir vienkārša: ACME klients pierāda domēna kontroli un saņem sertifikātu; pēc tam klients vai nu automātiski uzliek konfigurāciju, vai arī jūs manuāli norādāt ceļus uz sertifikāta failiem. Praksē vienkāršākais ceļš ir izmantot certbot ar atbilstošu “pluginu” jūsu web serverim, kas spēj automātiski izveidot vai pielāgot konfigurāciju. Ja jūs izmantojat pielāgotu Nginx/Apache konfigurāciju, var būt drošāk izmantot “certonly” režīmu, lai certbot ģenerē sertifikātu, bet konfigurāciju pielāgojat paši.
# Piemērs: izsniegt sertifikātu (certonly režīms) ar webroot certbot certonly --webroot -w /var/www/example.lv -d example.lv -d www.example.lv # Pārbaudīt atjaunošanu (dry-run) certbot renew --dry-run
Svarīgākais ir saprast, kur atrodas faili. Tipiski Let’s Encrypt glabā sertifikātu /etc/letsencrypt/live/DOMENS/ mapē. Web serverim parasti jānorāda fullchain.pem (sertifikāts + intermediate ķēde) un privkey.pem (privātā atslēga). Kad sertifikāts tiek atjaunots, faili tiek atjaunināti, bet serverim var būt jāveic reload, lai tas sāktu izmantot jauno sertifikātu. Tāpēc uzstādīšanā svarīgs ir arī “pēc-atjaunošanas āķis” (deploy hook) vai automatizēts reload.
4) Manuāla uzstādīšana: CSR, privātā atslēga, sertifikāta ķēde
Ja jūs uzstādāt komerciālu vai organizācijas validētu sertifikātu, process bieži sākas ar CSR ģenerēšanu. CSR satur publisko atslēgu un informāciju par domēnu. Privātā atslēga paliek tikai pie jums – to nekad nesūta CA. Pēc validācijas CA izsniedz sertifikātu un starpsertifikātus (intermediate), kas veido uzticības ķēdi līdz “root”. Ja ķēde nav uzstādīta pareizi, pārlūks var rādīt kļūdas pat tad, ja pats sertifikāts ir derīgs.
# CSR un privātās atslēgas ģenerēšana (RSA piemērs) openssl req -new -newkey rsa:2048 -nodes -keyout example.lv.key -out example.lv.csr # Pārbaudīt CSR saturu openssl req -in example.lv.csr -noout -text
Kad saņemat sertifikātu no CA, parasti jums būs vismaz divi faili: “server certificate” un “CA bundle”. Nginx bieži izmanto vienu “fullchain” failu, kurā ir gan servera sertifikāts, gan intermediate sertifikāti pareizā secībā. Apache dažreiz izmanto atsevišķus direktīvu laukus, bet mūsdienu konfigurācijās arī tur bieži lieto pilnu ķēdi vienā failā. Ja šī daļa ir neskaidra, drošākais ir pārbaudīt ar openssl, vai serveris tiešām sūta pilnu ķēdi.
5) Nginx konfigurācijas paraugs
Nginx konfigurācijā jūs parasti definējat server bloku uz 443 un norādāt sertifikāta ceļus. Papildus bieži iestata drošāku TLS konfigurāciju un pāradresāciju no HTTP uz HTTPS. Zemāk ir ilustratīvs paraugs; pielāgojiet ceļus un server_name savam domēnam. Ja izmantojat Let’s Encrypt, ceļi uz fullchain.pem un privkey.pem parasti atrodas /etc/letsencrypt/live/.
server {
listen 443 ssl http2;
server_name example.lv www.example.lv;
ssl_certificate /etc/letsencrypt/live/example.lv/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.lv/privkey.pem;
root /var/www/example.lv;
index index.php index.html;
}
Pēc izmaiņām vienmēr pārbaudiet konfigurācijas sintaksi un pārstartējiet vai pārlādējiet Nginx. “Reload” parasti ir drošāks, jo tas nepārtrauc aktīvos savienojumus. Ja jūs maināt tikai sertifikātu, bieži pietiek ar reload, lai Nginx sāktu izmantot jauno failu.
nginx -t systemctl reload nginx
6) Apache konfigurācijas paraugs
Apache vidē bieži izmanto VirtualHost uz 443 un ieslēdz mod_ssl. Līdzīgi kā Nginx, jānorāda sertifikāts un privātā atslēga. Dažās konfigurācijās var būt atsevišķs chain fails, bet bieži pietiek ar “fullchain” vienā failā. Pārliecinieties, ka ir ieslēgti vajadzīgie moduļi un ka virtuālais hosts tiešām atbilst domēnam, kuru atverat pārlūkā.
ServerName example.lv ServerAlias www.example.lv SSLEngine on SSLCertificateFile /etc/letsencrypt/live/example.lv/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/example.lv/privkey.pem DocumentRoot /var/www/example.lv
Pēc konfigurācijas maiņas pārbaudiet Apache un veiciet reload. Ja redzat kļūdas par ķēdi vai sertifikātu, pārbaudiet, vai norādītais fails tiešām satur pilnu ķēdi, un vai privātā atslēga atbilst konkrētajam sertifikātam.
apachectl configtest systemctl reload apache2
7) HTTP → HTTPS pāradresācija un “www”/saknes konsekvence
Lai lietotāji vienmēr nonāktu drošajā versijā, tipiski uz 80 porta izveido atsevišķu konfigurāciju, kas visu pāradresē uz HTTPS. Turklāt ir vērts izlemt, vai jūsu kanoniskais domēns ir ar www vai bez www, un tad pārējos variantus pāradresēt uz kanonisko. Tas palīdz izvairīties no sīkām SEO un cookie problēmām un padara uzvedību paredzamu.
server {
listen 80;
server_name example.lv www.example.lv;
return 301 https://$host$request_uri;
}
Ja ieslēdzat HSTS, dariet to pakāpeniski: sākumā ar mazu max-age un tikai pēc tam, kad esat pārliecināts, ka sertifikāta atjaunošana ir stabila. HSTS var padarīt kļūdas “lipīgas”, jo pārlūks nākotnē atsakās atvērt HTTP pat tad, ja jūs gribētu īslaicīgi atgriezties pie HTTP (kas publiskām vietnēm tik un tā nav ieteicams).
8) Mixed content: kāpēc slēdzenīte dažreiz “pazūd”
Pat ja sertifikāts ir uzstādīts pareizi, pārlūks var brīdināt par “mixed content”, ja daļa resursu tiek ielādēti ar HTTP: attēli, skripti, fonti vai iframe. Šādā gadījumā HTTPS savienojums ir, bet daļa satura nav droša. Risinājums ir atjaunot visas resursu saites uz HTTPS, izmantot relatīvas URL, un pārliecināties, ka trešo pušu skripti atbalsta HTTPS. Praktiski to diagnosticē pārlūka Console sadaļā.
9) Vadības paneļi (cPanel/ISPmanager/VestaCP): ko pārbaudīt
Ja izmantojat hostinga vadības paneli, uzstādīšana bieži notiek ar pāris klikšķiem: izvēlaties domēnu, ielīmējat sertifikāta saturu (PEM formātā) un privāto atslēgu, vai arī ieslēdzat automātisku Let’s Encrypt. Tomēr arī panelī ir vērts pārbaudīt detaļas: vai sertifikāts ir piesaistīts pareizajam domēnam un visiem alias (www), vai ir pievienota intermediate ķēde, un vai web serveris pēc izmaiņām tiešām ir pārlādēts. Dažos paneļos var atsevišķi būt “Certificate”, “Private Key” un “CA Bundle” lauki — nepalaidiet garām pēdējo, jo tieši tas bieži izraisa “untrusted” kļūdas.
Vēl viena praktiska pārbaude ir pārliecināties, ka privātā atslēga atbilst sertifikātam. Ja serverī saglabājas vairākas atslēgas no iepriekšējiem mēģinājumiem, var nejauši piesaistīt nepareizo. To var salīdzināt ar openssl (piemēram, pēc modulu “modulus” hash), un šī pārbaude nereti uzreiz pasaka, kāpēc web serveris atsakās startēt vai kāpēc TLS handshake izgāžas. Jo sarežģītāka ir infrastruktūra, jo vairāk šādas “higiēnas” pārbaudes taupa laiku.
Pārbaude, atjaunošana un biežākie “klupšanas akmeņi”
Pēc uzstādīšanas vienmēr pārbaudiet rezultātu no vairākām vietām un ar vairākiem rīkiem. Pārlūks parāda lietotāja pieredzi, bet komandrindas rīki palīdz redzēt, kādu sertifikātu serveris patiesībā sūta, vai ir pilna ķēde, un kādi protokoli tiek atbalstīti. Šis solis ir svarīgs īpaši tad, ja migrējat no viena servera uz citu vai ja vienā IP ir vairāki domēni.
openssl s_client -connect example.lv:443 -servername example.lv curl -I https://example.lv
Let’s Encrypt gadījumā stabilitāte nozīmē automatizāciju. Pārbaudiet, vai certbot renew tiešām darbojas (dry-run), un pārliecinieties, ka pēc atjaunošanas tiek izpildīts reload. Ja renewal pēkšņi sāk krist, biežākie iemesli ir: port 80 vairs nav pieejams, DNS ir pārslēgts citur, webroot ceļš ir mainīts, vai reverse proxy bloķē ACME challenge. DNS-01 gadījumā problēma bieži ir TXT vērtība vai pārāk lēna izplatīšanās.
Ja redzat pārlūka kļūdas, domājiet kategorijās. “Name mismatch” nozīmē, ka sertifikāts nesedz konkrēto hostname (piemēram, ir tikai www, bet jūs atverat sakni). “Untrusted” bieži norāda uz nepilnu ķēdi. “Expired” norāda uz atjaunošanas problēmu. “Wrong certificate” var norādīt uz SNI vai uz to, ka 443 konfigurācija atbilst citam server_name. Šāda pieeja saīsina diagnostikas laiku.
Praktisks kontrolsaraksts pēc uzstādīšanas: vai HTTPS atveras bez brīdinājumiem, vai sertifikāts sedz visus vajadzīgos vārdus, vai 80 ports pāradresē uz 443, vai nav mixed content, un vai atjaunošana ir automatizēta. Kad tas ir izpildīts, SSL uzstādīšanu var uzskatīt par pabeigtu, un jūs varat droši turpināt ar citām drošības lietām, piemēram, HSTS, CSP un cookie politiku.