OpenSSL ja sertifikaadid

• Selle praktikumi teemaks on erinevate signeeritud (CA-signed) sertifikaatide loomine, seadistamine ja kasutamine.
• Praktikumi töö toimub Linuxi virtuaalmasinas.

Sissejuhatus

Enne praktilise osani jõudmist anname lühiülevaate sellest, mis on sertifikaadid ning miks neid vaja on.

Ajalooliselt kulges suur osa veebiliiklusest krüpteerimata kujul (HTTP vahendusel) ning on seetõttu pealtkuulatav. Mõnikord pole krüpteerimist vajagi, sest näiteks uudisteportaalid või Vikipeedia jagavad avalikku infot, mida ehk ei ole vaja varjata. Samas ei taga HTTP kasutamine sisu terviklikkust, mistõttu te ei saa olla kindlad kas see info, mis teie ekraanile jõudis on autentne või on keegi vahepeal pakettide sisu muutnud. Uudisteportaalis olev sisu pole salajane, aga samas saaks aktiivne ründaja, kes kontrollib interneti teenusepakkujat, mõne artikli sisu edastada muudetud kujul.

Suuremad probleemid tekivad siis, kui turvalisus ja privaatsus muutub oluliseks - näiteks kreeditkaardi või e-tervise infosüsteemi kasutamisel. Transpordikihi turbeprotokolli TLS (Transport Layer Security, varasemalt turvasoklite kihti (Secure Sockets Layer, SSL)) kasutatakse sõnumite krüpteerimiseks suhtluskanali otspunktide vahel.

TLS pakub:

• andmete konfidentsiaalsust
• serveri autentimist sertifikaadi abil
• andmete terviklust ja andmete autentimist
• (kliendi autentimist kliendisertifikaadi abil)
• (Perfect Forward Secrecy ehk PFS)

TLS kasutab andmeside konfidentsiaalsuse tagamiseks hübriidsüsteemi, mis kasutab nii sümmeetrilist kui ka asümmeetrilist krüpteerimist. Sümmeetrilist krüpteerimist läheb vaja selleks, et pakettides omavaid andmeid kaitsta. Samas ei saa ainult sümmeetrilist krüpterimise kasutades lahendada võtmejagamise probleemi. Asümmeetrilist ehk avaliku võtme krüptograafiat lähebki vaja selleks, et näiteks veebiserver ja brauser saaksid omavahel kokku leppida AES võtme. Ainult avaliku võtme krüptograafiast ei piisaks, sest see on liiga aeglane sessiooni krüpteerimiseks. On oluline aru saada, et TLS krüpteerib võrguühenduste segmente transpordikihis suhtluskanali otspunktides (näiteks veebiserveri ja brauseri vahel) ja pakette edastavad osapooled ei näe krüpteeritud pakettide sisse.

Avaliku võtme krüptograafia lahendab küll võtme jagamise probleemi, aga kohe tekib uus probleem. Kuidas on võimalik kindlaks teha, kellele vastav avalik võti kuulub? Selle probleemi lahendamiseks kasutatakse sertifikaate ja sertifitseerimiskeskuseid ehk avaliku võtme infrastruktuuri (PKI). Sertifikaat seob ära avaliku võtme ja võtme omaniku. Avalik võti võib kuuluda näiteks veebilehele (HTTPS kasutamise korral), aga ka eraisikule (näiteks ID-kaardi / Mobiil-ID). Niisugust sertifikaati on võimalik ise genereerida, aga see ei kaota usalduse probleemi, sest kolmandad isikud ei saa kindlaks teha, kas sertifikaadis olev info vastab tõele või on võltsitud. Selle probleemi lahendamiseks kasutatakse kolmandaid usaldatud osapooli ehk sertifitseerimiskeskuseid (CA - certificate authority), kes allkirjastavad sertifikaate ning kinnitavad, et vastav avalik võti kuulub sertifikaadis kirjeldatud isikule / asutusele. Selleks, et avaliku võtme infrastruktuur toimiks, peab teie operatsioonisüsteem või brauser usaldama piisavat hulka tipmisi sertifitseerimiskeskuseid (CA). Uurige enda brauseri seadistust, kui teid huvitab, missuguseid sertifitseerimiskeskusi te vaikimisi usaldate.

Kõik, mis on krüpteeritud avaliku võtmega, on dekrüpteeritav ainult vastava salajase võtmega ja vastupidi. Salajase võtmega krüpteerimist nimetatakse ka signeerimiseks ehk digi-allkirjastamiseks. Kui server saadab veebilehitsejale enda sertifikaadi, mis on krüpteeritud serveri enda salajase võtmega, siis seda sertifikaati nimetatakse endasigneeritud (self-signed) sertifikaadiks. Kuna allkirja kontrollimiseks tuleb kasutada vastavat avalikku võtit, siis pannakse see sertifikaadiga kaasa. Kui pöördute serveri poole, millel on sertifikaat, kuid mis ei ole allkirjastatud usaldusväärse CA poolt, siis on võrguliiklus küll krüpteeritud, kuid te võite suhelda osapoolega, kes ei ole see, kes väidab end olevat.

Siiski on ka endasigneeritud sertifikaadil oluline roll olukorras, kus soovite krüpteerida andmesidet enda poolt ülesseatud veebiserveriga. Teie enda poolt allkirjastatud sertifikaadi kasutamisel kuvab brauser hoiatuse ning te peate sertifikaadi brauseris käsitsi kinnitama. Endasigneeritud sertifikaadi kasutamine usaldusväärse CA poolt väljaantud sertifikaadi asemel on tänapäeval pigem haruldane. Varasemalt kasutati seda võimalust, sest CA-de teenused on üldjuhul tasulised ning ei olnud tasuta alternatiivi. Praegu seda probleemi enam ei eksisteeri, enda veebilehele saab https://letsencrypt.org/ kaudu hankida tasuta kolmanda osapoole sertifikaadi.

Praktikumi ettevalmistus

Looge endale isiklik openssl töökeskkond: (eeldame edaspidi, et see asub /home/kasutaja/openssl)

Nende käskude tulemusena loodi mitu tühja kausta, mida edaspidiselt kasutatakse sertifikaatide loomisel erinevate failide hoidmiseks.

Järgnevalt peame seadistama sertifikaadi loomise parameetrid openssl.cnf failis.

 DNS.0 = *.<perenimini>.sec
 DNS.1 = <perenimi>.sec
 DNS.2 = www.<perenimi>.sec
 DNS.3 = mail.<perenimini>.sec

7.1 Endasigneeritud (Self-signed) sertifikaat

Nüüd teete endasigneeritud sertifikaadi, mida ükski teine osapool ei kontrolli ega allkirjasta.

Kontrollige, et hetkel aktiivne töökataloog oleks /home/kasutaja/openssl ning aktiivne kasutaja on "kasutaja"!

Sertifikaadi tegemisel kasutate võtmesõna x509, mis on Rahvusvahelise Telekommunikatsiooni Liidu poolt loodud standard ning käsitleb avaliku võtme infrastruktuuris kasutatavaid digisertifikaate .

$ openssl req -config /home/kasutaja/openssl/openssl.cnf -new -x509 -out sscert.pem

Pärast käsu sisestamist küsitakse teilt parooli, millega hakatakse kaitsma salajast võtit. Parool peab olema vähemalt nelja sümboli pikkune ning teil tuleb see parool meelde jätta.

Pärast parooli sisestamist tuleb teil kanda info sertifikaadile (enamike küsimuste korral võite ENTER klahviga kinnitada vaikevalikud, mille olime eelnevalt openssl.cnf failis seadistanud).

Oluline on Common Name väärtuseks sisestada korrektne arvuti nimi (<perenimi>.sec). <perenimi>.sec tähistab järgnevates käskudes teie arvuti nime (hostname), mis peab olema igal pool olema sama ja võiks olla teie perekonnanimi ning lõppu lisage .sec. Igal arvutil peaks olema unikaalne nimi, nt teie perekonnanimi, kontrollige arvuti nime failidest /etc/hostname ja /etc/hosts):

Uurige loodud sertifikaati:

$ openssl x509 -text < sscert.pem | less 

7.2 Apache veebiserver ja SSL

Nüüd pange arvutis jooksma Apache veebiserver ning seadistage see kasutama varasemalt loodud sertifikaati.

Apache konfiguratsioonifailid asuvad kaustas /etc/apache2 ning võimaldavad seadistada paljusid funktsionaalsusi (lisamoodulid, virtuaalserverid).

Kaust sites-available sisaldab veebilehtede konfiguratsioonifaile. Selleks, et neid tegelikult lubada, tuleb teha link kausta sites-enabled. Konfiguratsioonifaile võib ka otse kopeerida, kuid korduste vältimiseks tuleb teha link. Lingi saab teha ln käsuga, kuid sõltuvuste kontrolliks on parem kasutada spetsiaalseid apache ümberseadistamise käske (informatiivne, ärge neid praegu sisestage):

 # a2ensite site-name (aktiveerib virtualhosti) 
 # a2dissite site-name (deaktiveerib virtualhosti) 
 # a2enmod mod-name (aktiveerib mooduli) 
 # a2dismod mod-name (deaktiveerib mooduli) 

NB! Edaspidi jälgige hoolikalt, kas käsud tuleb käivitada tavakasutaja ($) või root kasutaja (#) õigustes!

Installeerige Apache veebiserver ja konfigureerige see SSL-i kasutama (<perenimi>.sec on taas teie arvuti nimi):

$ sudo apt update (soovitav kasutada alati enne installeerimist)
$ sudo apt install apache2
$ sudo a2enmod ssl
$ sudo a2enmod cgi
- lisage /etc/apache2/apache2.conf faili lõppu (enne "IncludeOptional sites-enabled/" rida) järgnev rida:  
ServerName <perenimi>.sec
$ sudo service apache2 restart 
$ sudo service apache2 status

Apache uuestikäivitamise ajal ei tohi ühtegi viga tulla. Kui siiski tuleb siis parandage, kuni enam ei ilmu. Apache staatust soovitame kontrollida pärast igat Apache restarti. See aitab veenduda, et teenus käivitus ilma probleemideta.

NB! Apache veateateid saab täpsemalt uurida logi failist asukohas: /var/log/apache2/error.log!

Looge uus ssl kaust Apache kausta sisse ning kopeerige sinna oma sertifikaat ja salajane võti:

$ sudo mkdir /etc/apache2/ssl
$ cd /home/kasutaja/openssl
$ sudo cp sscert.pem /etc/apache2/ssl/server.crt
$ sudo cp privkey.pem /etc/apache2/ssl/server.key

Muutke Apache SSL virtuaalhosti konfiguratsioonifaili /etc/apache2/sites-available/default-ssl.conf. Lisage järgmine rida (näiteks kohe pärast ServerAdmin webmaster@localhost rida):

kus <perenimi>.sec on teie arvuti nimi ja seadistage sertifikaadi ja võtme asukohad korrektseks:

SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Nüüd lülitage Apache virtuaalhosti SSL tugi sisse:

$ sudo a2ensite default-ssl
$ sudo service apache2 restart 

Apache peaks nüüd käivitamisel küsima salajase võtme parooli. Kindlasti kontrollige, et Apache läks korrektselt tööle (vihje: kontrollige teenuse staatust).

NB! Kuna Apache küsib parooli, siis arvuti taaskäivitamisel apache enam automaatselt tööle ei lähe. Arvuti uuesti käivitamisel jääb protsessitabelisse ps ripakile parooliküsimine. (/bin/bash /usr/share/apache2/ask-for-passphrase <perenimi>.sec:443 RSA) Seetõttu tuleb hiljem arvuti taaskäivitamisel Apache protsess kill käsuga seisata ja Apache teenus uuesti käivitada käsitsi: sudo service apache2 start

Testige jooksva süsteemi sertifikaadi olemasolu allpool oleva 'openssl s_client' käsu abil: (parandage kuni vigu ei esine ja saate teha GET / päringu)

$ openssl s_client -host <perenimi>.sec -port 443 -showcerts

Kui soovite kasutada mõne teise arvuti veebiserverit, siis tekitage /etc/hosts faili rida:

Käivitage Firefox veebibrauser ja avage oma masinas veebiserveri lehekülg: https://<perenimi>.sec/. Veebibrauser peaks sertifikaadi üle kurtma. Vali Advanced -> Add Exception ->Avanenud aknas Confirm Security Exception, uuri pakutud sertifikaati ja kontrolli kas see on sama, mille enne tegid! Kinnita erand. Võid proovida sama teha ka naabri serveriga (lisa enne /etc/hosts faili naabri IP ja nimi).

Pärast veebibrauseri taaskäivitust ei tohiks sertifikaadi üle enam kaebusi tekkida.

Uurige Firefox veebibrauseris aktiivseid seritifikate (Edit -> Preferences -> Privacy & Security -> Certificates -> View Certificates -> Servers) - leidke sealt enda loodud sertifikaat. Nüüd kustutage see sertifikaat.

Nüüd kustutage ka varasemalt loodud sertifikaat ja võti: (kontrolli, et oled "kasutaja")

$ cd /home/kasutaja/openssl
$ rm privkey.pem sscert.pem

7.3 Sertifitseerimisorgan - Certification Authority (CA)

Sertifitseerimisorgan on usaldatav kolmas osapool, kelle ülesanne on verifitseerida asutuste ja süsteemide sertifikaate. Sertifitseerimisorgan kontrollib üle sertifikaadi taotleja (asutuse või isiku) identiteedi ning allkirjastab väljastatava sertifikaadi kinnitamaks, et see sertifikaat on sertifitseerimisorgani poolt üle kontrollitud ja usaldatud.

Nüüd tehke sertifikaadi loomine uuesti läbi, aga seekord loote lisaks ka sertifitseerimisautoriteedi sertifikaadi ning kasutate seda veebilehe sertifikaadi allkirjastamiseks.

Tekitage sertifitseerimisorgani (Certification Authority, CA) sertifikaat. Common Name väärtuseks määrake Sertifitseerimiskeskus (parooliks pange caparool )

$ openssl req -new -x509 -days 3650 -keyout /home/kasutaja/openssl/private/cakey.pem -out /home/kasutaja/openssl/cacert.pem  -config /home/kasutaja/openssl/openssl.cnf

Nüüd lisage loodud sertitseerimiskeskuse sertifikaat Firefox usaldatud sertifitseerimiskeskuste nimekirja. Selleks tuleb minna "Edit -> Preferences -> Privacy & Security -> Certificates -> View Certificates -> Authorities -> Import..." ja valida importimiseks cacert.pem ning märkida, et usaldatakse selle sertitseerimiskeskuse poolt välja antud sertifikaate (tehke linnuke kõigi (2) valiku juurde).

Kui see on tehtud, siis teie veebibrauser usaldab kõik antud sertifitseerimiskeskuse poolt väljastatud sertifikaate ning enam ei teki hoitust. Kui keegi tahab tulevikus enda veebilehe / kodulehe jaoks usaldusväärset sertifikaati saada, siis peaks selle allkirjastama usaldusväärne sertifitseerimiskeskus. Enamasti küsivad suured sertifitseerimiskeskused sertifikaadi allkirjastamise eest raha, aga teatud tingimustel on võimalik saada ka tasuta allkirja. Seda võimalust pakub näiteks Let's Encrypt.

Järgmise sammuna tekitage enda veebilehele uus sertifikaadipäring. Selle loomisel peaks parooliks seadistama serveriparool ning Common Name väärtuseks panema kindlasti: <perenimi>.sec (ehk hostname)

$ openssl req  -new -keyout newkey.pem -out newreq.pem -days 1095 -config /home/kasutaja/openssl/openssl.cnf

(ignoreerige (s.t. jäta tühjaks) "extra" attributes - challenge password ... )

Kasutades CA võtit väljastage sertifikaat (minge selle jaoks openssl kausta, sest siis on kõik vajalikud failid samas kaustas):

$ openssl ca -config /home/kasutaja/openssl/openssl.cnf -policy policy_anything -out newcert.pem  -infiles newreq.pem

Eelmise käsu käivitamisel küsitakse teilt cacert.pem faili parooli milleks eelnevaks seadistasime caparool

Kopeerige uued sertifikaadid Apache kausta:

$ sudo cp newcert.pem  /etc/apache2/ssl/server.crt
$ sudo cp newkey.pem  /etc/apache2/ssl/server.key
$ sudo cp cacert.pem /etc/apache2/ssl/cacert.crt

Tehke Apache teenusele taaskäivitus:

• Apache küsib nüüd käivitades serveri sertifikaadi parooli milleks eelnevalt seadistasime serveriparool

$ sudo service apache2 restart

Seadistame Apache sertifikaadi infot väljastama

Lisage / Muutke väärtused / Kommenteerige sisse (s.t. eemaldage kommentaar) failis /etc/apache2/sites-enabled/default-ssl.conf järgmised read:

SSLVerifyClient optional
SSLVerifyDepth 2

SSLOptions +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars +ExportCertData
</FilesMatch>

Tekitage (rooduna) CGI skript $ sudo nano /usr/lib/cgi-bin/env.cgi järgmise sisuga:

#!/bin/bash

cat <<EOF
Content-type: text/html

<html>
<pre>
`env`
</pre>
</html>
EOF
exit 0

7.4 Kliendisertifikaat

Selles ülesandes vaatame, kuidas lisaks veebiserverile on võimalik ka kasutajale sertifikaat luua ning seda kasutaja autentimisel kasutada. Igapäevaselt puutute te kliendisertifikaadil põhineva autentimisega kokku, kui te kasutate autentimiseks ID-kaarti või Mobiil-ID. Kliendisertifikaadi kasutamist illustreeritakse järgneval joonisel:

Allikas: Cloudflare

Järgmiseks ülesandeks ongi kliendisertifikaadi genereerimine. Kontrollige, et asute töökataloogis /home/kasutaja/openssl ning seejärel kontrollige, et olete õige "kasutaja" õigustes. Kopeerige ridasid ühekaupa!
Kliendi Common Name on nüüd füüsilise isiku nimi ehk teie enda täisnimi.

Klient tekitab sertifikaadi taotluse ja CN väljale paneb enda täisnime (ilma täpitähtedeta). Parooliks võiksite määrata kliendiparool.

$ openssl req  -new -keyout klientkey.pem -out klient.pem  -days 360 -config /home/kasutaja/openssl/openssl.cnf

Klient "saadab" taotluse CA-le (fail klientkey.pem) ning selle põhjal genereerib CA kliendile sertifikaadi, allkirjastab selle ja "saadab" tagasi kliendile (klientcert.pem). Järnev käsk küsib jälle CA sertifikaadi parooli milleks eelnevalt seadistasime caparool

$ openssl ca -config /home/kasutaja/openssl/openssl.cnf  -policy policy_anything -out klientcert.pem  -infiles klient.pem

Klient konverteerib sertifikaadi veebibrauseri jaoks sobivasse PKCS#12 formaati (nüüd võiksite parooliks seadistada samuti kliendiparool). Järgnevalt küsitakse teie käest ekspordi parooli, selle võite tühjaks jätta (hiljem brauserisse kliendisertifikaati importides jätke ka parooliväli tühjaks):

$ openssl pkcs12 -export -in klientcert.pem  -inkey klientkey.pem -certfile cacert.pem -name "test" -out test.p12

Praktikumi ülesande lahenduseks esitage täissuuruses ekraanivaade virtuaalmasina https://www.<perenimi>.sec/cgi-bin/env.cgi leheküljest FireFox veebilehitsejas ja https://mail.<perenimi>.sec/cgi-bin/env.cgi Google Chrome browseris. Lahednusel peab kindlasti näha ja esile tõstetud (märgistatud) olema SSL_CLIENT_S_DN rida, mis peab sisaldama teie kliendisertifikaadis leiduvaid kliendi kohta käivaid andmeid (teie ees- ja perekonna nime).

Korrektne lahendus peaks sarnanema järgneval pildil kujutatule:

Proovimiseks

Järgnev osa on vabatahtlik.

Proovime cgi'd kõrvalmasinast, selleks muuda /etc/hosts faili!

Muudame SSLClientVerify: optional require'ks - nüüd saab ligi ainult meie CA poolt väljantud kliendisertifikaadiga.

Proovime uuesti kõrvalmasinast (genereeri naabri jaoks teine kliendi sertifikaat!)

Tekita tühistusnimekiri (CRL), õpeta seda veebiserverile ja tühista kliendisertifikaat. Kontrolli, kas veebiserver sai aru.

Uuri, mis sertifikaatidega töötavad HTTPS veebiserverid: www.sk.ee, mailhost.ut.ee, www.swedbank.ee, www.seb.ee

Tagasiside

Praktikumi lõpus palume anda tagasisidet, sest see võimaldab meil antud praktikumi ja ka järgmisi praktikume paremaks muuta. Tagasiside on anonüümne ja tagasiside vormi leiate järgneva lingi abil: tagasiside ankeet.

Praktikumi ülesanded

Praktikumi ülesannete lahendamine annab kaks punkti. Praktikumi ülesanne võiks valmis saada praktikumi lõpuks, aga juhul kui see ei õnnestu, siis on võimalik lahendust esitada nädala jooksul praktikumi toimumisest.

Praktikumi ülesande lahenduseks esitage täissuuruses ekraanivaade virtuaalmasina https://www.<perenimi>.sec/cgi-bin/env.cgi leheküljest FireFox veebilehitsejas ja https://mail.<perenimi>.sec/cgi-bin/env.cgi Google Chrome browseris. Ekraanivaatel peab kindlasti olema näha ja esile tõstetud (märgistatud olema) SSL_CLIENT_S_DN rida, mis peab sisaldama teie kliendisertifikaadis leiduvaid kliendi kohta käivaid andmeid (teie ees- ja perekonna nime).

Lahendusi võtame vastu järgmistes failiformaatides: .pdf, .jpg, .png.

Kodune ülesanne

Koduse ülesande lahendamine annab ühe punkti. Lahenduse esitamiseks on aega üks nädal s.t. selle päeva lõpuks, mil on järgmine praktikum. Küsimustele vastuste leidmiseks võib vaja minna lisamaterjalide, millest osa leiate antud praktikumi lehelt.

1. Võrrelge tavalist kasutajanime ja parooliga autentimist vs. kliendisertifikaadi abil autentimisega. (0.6p)

• Mis on kummagi viisi eelised ja puudused - nii turvalisuse kui ka kasutusmugavuse vaatepunktidest?
• Eeldame et mõlemad töötavad üle HTTPS (TLS) ühenduse
• Vastusevariandid peavad olema sisuliselt erinevad ja tehniliselt detailsed.
• Vastuseid ootame kujul (vähemalt 3 eelist ja 3 puudust sertifikaadi ja parooli kohta):

1. Kasutaja:Parool eelised
   1. ...
   2. ...
   3. ...
2. Kasutaja:Parool puudused
   1. ...
   2. ...
   3. ...
3. Kliendisertifikaadi eelised
   1. ...
   2. ...
   3. ...
4. Kliendisertifikaadi puudused
   1. ...
   2. ...
   3. ...

2. Turvalisus on nii kõrge kui sinu IT-süsteemi nõrgim lüli ning turvaaugu leidmiseks on olemas mitmeid automatiseeritud teste. Mine lehele https://www.ssllabs.com/ssltest ja testi enda enimkasutatud veebilehtede turvalisust.

Esitada: https://www.ssllabs.com/ssltest link vähemalt ühele KÕRGE TURVALISUSEGA (A või enam) ja ssllabs link ühele MADALA TURVALISUSEGA (B või vähem) veebilehele. (0.4p)

Näide (neid ei või vastuses kasutada):

• Kõrge turvalisusega https://www.ssllabs.com/ssltest/analyze.html?d=courses.cs.ut.ee&s=193.40.36.57&latest
• Madala turvalisusega https://www.ssllabs.com/ssltest/analyze.html?d=mailhost.ut.ee&s=193.40.5.66&latest

Juhul kui lahenduseks on lühike tekst, siis saate lisada selle kommentaarina. Sellisel juhul on lahenduse esitamiseks vaja lisada tühi fail, sest antud vorm nõuab lahenduse esitamisel faili esitamist. Koduse ülesande lahendus tuleks esitada aine kodulehelt. Korraga saab esitada ainult ühe faili, korduv lahenduse esitamine kirjutab eelmise lahenduse üle ning seetõttu tuleb vajaduse korral lahendus kokku pakkida üheks failiks. Lahendusi võtame vastu järgmistes failiformaatides: .txt, .pdf ja pildifailid.

Lisamaterjalid

• Andrese lisamaterjalid

• OpenSSL
  • Projekti koduleht
  • OpenSSL wikipedia leht
  • Näited sagedamatest käskudest
• Self-signed sertifikaat
  • Wikipedia artikkel
  • Kuidas teha ja millal kasutada
  • Mõned pakkujad
• Muud
  • Parool või sertifikaat