Asiakkaaksi ryhtyminen (20 euron ennakkomaksu PayPal-palvelua käyttäen)

Julkaisusovelluksen tarvitseman palvelimen käyttöönotto aloitetaan asiakaskohtaisesti aina ns. tyhjästä eli jokaista asiakasta varten rekisteröidään datakeskus-palveluiden tarjoajalle käyttäjätunnus, jolla julkaisusovelluksen palvelin voidaan sitten ottaa käyttöön.

Datakeskus-palveluiden tarjoajia on useita ja eräänä erittäin kelpoisena on tuntunut olevan Hetzner, jonka palvelimet voivat sijaita myös Suomessa. Alkuvaiheen rahaliikenne Hetznerin tapauksessa kulkisi kuvan 1 mukaisesti eli PayPal-palvelulla ennakkomaksu julkaisusovelluksen kehittäjän PayPal-tilille, josta se siirretään heti pian Hetznerille ennakkomaksuna. Myöhemmin asiakas voi maksaa Hetznerin laskut vaikka suoraan tilisiirtoina.

Muilla datakeskus-palveluiden tarjoajilla ei välttämättä ole ennakkomaksun mahdollisuutta, joten niiden osalta rahaliikenne kulkisi alkuvaiheessa ja ehkä myöhemminkin kuvan 2 mukaisesti, mikä voi tarkoittaa myös hiukan nopeampaa käyttöönottoa.

Julkaisusovelluksen palvelimen perusominaisuudet ja kuukausihinta

Resursseja kuten levytilaa, muistia/tehoa palvelinlaitteeseen/-teisiin on saatavilla pyydettäessä. Vähimmäisresursseina palvelimelle on todettu sopivaksi 4 GB muistia, ja 3 vCPU (prosessorin aikasäikeitä). Palvelin on tyypiltään virtuaalipalvelin eli esim. prosessoria käyttää useampikin datakeskus-palveluiden tarjoajan asiakas. Dedikoitujen eli yhden asiakkaan käyttöön tarkoitettujen palvelimien hinnat ovat kalliimpia. Hyvin riittäviksi perusresursseiksi määritellyillä resursseilla virtuaalipalvelimen kuukausimaksu olisi jotakuinkin 5 - 15 euron välillä. Julkaisusovelluksen hajauttaminen useille palvelimille toimii, mutta palvelinten välinen tiedon synkronointi saattaa aiheuttaa ongelmia, joita ei ole tullut esille testauksessa, joten toistaiseksi julkaisusovellus sijoitetaan vain yhdelle palvelimelle, jonka resursseja sentään voi vaihtaa.

Palvelimelta ulospäin suuntautuvan datan (kuvat ym.) hinnoittelussa on eri datakeskus-palveluiden tarjojien välille erittäin paljon vaihtelua, mutta sekä sen, että levytilan määrän pyritään ottamaan käyttöön sellaisia vaihtoehtoja, että niitä voisi luonnehtia olevan suhteellisen runsaasti. Kuvan 3 CPX21-palvelin Hetznerillä mahdollistaa jopa 20 TB:n outbound-dataliikenteen ennen kuin siitä alettaisiin laskuttamaan erikseen. Käytännössä tämä raja ei edes voi ylittyä, koska julkaisusovellus konfiguroidaan sen verran dataliikennettä rajoittavaksi, ettei dataliikennettä pääse kertymään liiaksi. Tästä kuten monestakin muustakin seikasta voidaan sopia erikseen.

Vaaditaan käyttöönotettavaksi: CDN-palvelu (10 eur per vuosi PayPal-maksuna)

Julkaisusovellus kestää paljon paremmin käyttäjien aiheuttamaa kuormitusta ja teoksissa käytetyt kuvat latautuvat nopeammin, kun niitä ei aina ladata suoraan julkaisusovelluksen käyttämältä palvelimelta, vaan käyttäjän ja palvelimen väliin tulevasta CDN-palvelusta. Lyhenne CDN tulee sanoista Content Delivery Network, mikä tarkoittaa esim. teoksissa käytettyjen kuvien tapauksessa sitä, että ne saapuvat käyttäjän selaimeen lähimmältä mahdolliselta CDN-palvelun PoP-palvelimelta, joita on nykyisin myös Suomessa.

Hinnoittelu ja erityistä mainittavaa: CDN-palvelu (BunnyCDN) voidaan esikonfiguroida valmiiksi asiakasta varten rekisteröimällä siihen yksi uusi käyttäjätunnus, tekemällä tarvittavat säädöt ja vaihtamalla sitten CDN-palvelun käyttäjätunnuksen sähköpostiosoite, jotta asiakas voi kirjautua siihen ja liittää käyttäjätunnukseen maksutietonsa. PayPal-käyttäjätunnus asiakkaalla tässä vaiheessa jo olisikin, joten sen käyttö on suositeltavaa (otettava käyttöön viimeistään 14 päivän kokeiluajan jälkeen). BunnyCDN:ssä on käytössä sääntö, jonka mukaan asiakkaan on kerran vuoteen maksettava ennakkomaksua vähintään 10 eur. Aiemmin maksettu ennakkomaksu ei ekspiroidu koskaan. Tuolla 10 eurolla saa datansiirtoa 1 TB, mikä riittänee vähäliikenteiselle sivustolle vaikka koko vuodeksi. Jos ennakkomaksut pääsevät loppumaan, julkaisusovelluksen kuvia ei jaella CDN-palvelun kautta ennen kuin CDN-palvelun ennakkomaksua maksetaan lisää. Näitä ennakkomaksua ei voi saada takaisin niiden maksamisen jälkeen.

Ohje: CDN-palvelun käyttöönottamiseksi on erillinen kuvien avulla selittävä kirjoituksensa (ks. kirjoitus "Ohje CDN-palvelun käyttöönottoon").

Erikseen ostettu verkkotunnus

Julkaisusovellusta pääsee käyttämään Internetistä heti, kun se on asennettu. Asiakkaaksi ryhtymisen alkuvaiheen yhteydenotoissa sovitaan, käyttääkö julkaisusovellus aluksi jotain tietynlaista aliverkkotunnusta esim. testaamistarkoituksiin vai hankitaanko samantien erillinen verkkotunnus. Verkkotunnuksia (eng. domain) voi ostaa lukuisilta eri tahoilta (esim. Namecheap), joilla on tyypillisesti myös (jonkinlainen) hallintakäyttöliittymä. Ostettu verkkotunnus on aina siirrettävissä rekisterinpitäjältä toiselle ellei ostamisen yhteydessä ole luopunut joistakin oikeuksistaan kuten omistusoikeuksista. Tällä erää on aikeiltu, että julkaisusovelluksen asiakas ostaisi verkkotunnuksen itse, koska se sujuu noviisiltakin ja täten ei tarvitse käydä siirtelemään omistusoikeuksia.

Hinnoittelu: Jos ei tarvitse erikoista verkkotunnuksen päätettä, tavanomainen vähimmäishinta saattaisi olla hiukan alle kymmenen euroa per vuosi. Ensimmäisen vuoden saattaa usein saada ilmaiseksikin tai hyvällä alennuksella. Erilaisia verkkotunnuksien päätteitä on useita satoja.

Ohje: Erikseen hankitulle verkkotunnukselle täytyy asettaa nämä nimipalvelimet (ks. kuva 4): hydrogen.ns.hetzner.com, oxygen.ns.hetzner.com ja helium.ns.hetzner.de.

Erityistä mainittavaa: Ei suurempaa merkitystä, mutta mainittakoon pikanttina tietona, että jos IPV4-tyyppisiä osoitteita ei ole saatavilla julkaisusovelluksen käyttöön niiden globaalin vähiin käyvyyden vuoksi, käytetään IPV6-osoitteita, joista esim. Cisco tietää kertoa lisää: https://www.ciscopress.com/articles/article.asp?p=2803866

Ennakkomaksujen takaisinmaksu

Ainakin Hetznerin tapauksessa ennakkomaksut voi saada takaisin jäljellä olevan summan osalta (miinus viimeisen laskun loppusumma) ja voisihan sitä senkin luvata, että jos asiakkaan rahoja on vielä julkaisusovelluksen PayPal-tilillä ja laskut on maksettu, asiakas saa jäljelle jäävän summan takaisin itselleen.

Hetznerin asiakaspalvelulta saadun tiedon mukaan heillä rahojen palautus tapahtuu sitä maksuvälinettä käyttäen, jolla maksut alun perin suoritettiin eli PayPal-maksut julkaisusovelluksen myyjän kautta PayPal-tilille ja tilisiirrot suoraan julkaisusovelluksen asiakkaan pankkitilille. Siihen ei aivan ole saatu selvyyttä, aiheutuuko tilisiirtona tapahtuvasta palautuksesta palvelumaksua kuten rahaa lähetettäessä, mutta ei sen SEPA-alueella (Single Euro Payments Area) pitäisi olla kovinkaan paljon.

Asiakkuuden vakiintuminen

Jos datakeskus-palveluiden tarjoaja ei mahdollista ennakkomaksujen vastaanottamista, asiakas voi silti siirtää laskennallisten kuukausien edestä ennakkomaksuja julkaisusovelluksen kehittäjän PayPal-tilille tai ehkä helpommin, siirtää jonkun suurpiirteisen summan, josta riittää yhteen tai useampaan kuukausimaksuun.

Jos datakeskus-palveluiden tarjoaja kuten Hetzner mahdollistaa ennakkomaksujen vastaanoton sinne asti, asiakkaan rahat siirtyvät alkuvaiheen tavoin suoraan eteenpäin julkaisusovelluksen kehittäjän PayPal-tililtä. Hetznerillä on myös se erikoisuus, että asiakas voi halutessaan maksaa laskut suoraan sille käyttämällä tilisiirtoa. Tällöin Hetzner vähentää palvelinmaksut automaattisesti ns. Credit Balancesta kerran kuukaudessa. Tilisiirtoa tehdessä viitetietoihin laitetaan Hetzner-käyttäjätunnuksen id-koodi, jotta lähetetty rahasumma ohjautuisi oikean käyttäjätunnuksen käyttöön.

Erikseen pyydettäessä asiakas voi saada kopion kuukausilaskusta, mutta tämä on manuaalinen toimenpide, joten kuukausittain samoina toistuvista laskuista ei välttämättä käydä jokaista erikseen kopiona lähettelemään. Eräänä vaihtoehtoina joillain datakeskus-palveluiden tarjoajille on mahdollisuus kutsua eräänlaiseen tiimiin henkilö, jolle annetaan sillä tapaa rajoitetut oikeudet, että hän pääsee näkemään kaikki laskut ja kenties maksamaankin ne samaisessa käyttöliittymässä.

Enemmän yritysmäinen toiminta vielä edessäpäin

Julkaisusovelluksen myyntiä ei vielä tehdä yritysmuotoisesti, vaan yksityishenkilönä ilman esim. toiminimeä tai kevytlaskutuspalveluiden käyttöä, joten tässä vaiheessa asiakas ei maksa lisähintaa tuotekehityksestä, ylläpidosta ym. Samaisesta syystä rahaliikenteessäkin on vielä tietynlaista kommervenkkiä.

Ei vielä käytössä: suojattu yhteys kaikille testaustarkoituksiin käytetyille verkko-osoitteille

Tässä vaiheessa, kun kustannuksien kertymistä julkaisusovelluksen kehittäjälle vältellään, ei ole otettu käyttöön suojattua yhteyksiä mahdollistavaa SSL-sertifikaattia, mutta jossain vaiheessa voisi ottaa käyttöön wildcard-tyyppisen (ks. kuva 5) SSL-sertifikaatin, jolloin yhdellä sellaisella saa suojauksen käyttöön kaikilla testaustarkoituksiin käytetyn verkkotunnuksen aliverkkotunnuksilla. Tämä ei tulisi asiakkaiden maksettavaksi, vaan tämä vain mainitsemisen vuoksi mainittuna. Käyttäjätunnuksiselle julkaisusovelluksen käyttäjälle osittain suojatun yhteyden julkaisusovellukseen saa VPN-yhteydellä. Lisätietoa kirjoituksessa "Perusteluja ja ohjeita verkko-osoite -kohtaisen SSL-sertifikaatin hankintaan, VPN-yhteys sen osittaisena korvaajana".

Tuntuman saamiseksi Credit balancen lisäämisestä on kokeiltu tehdä tilisiirto Hetznerille kahdella eri tavalla: tilisiirtona suoraan omasta pankista (Nordea) ja Wise-palvelua käyttäen. Eräänä torstaina maksettu molemmat ja heti viikonlopun jälkeisenä maanantaina Credit balance oli lisääntynyt molempia vaihtoehtoja käyttäen. Palvelumaksun määrä Wisen kohdalla täsmäsi eksaktisti siihen, mitä lähetetystä summasta päätyi Hetznerille. Oma pankki ei veloittanut palvelumaksua. Tapahtumienkulkuja on varmastikin nopeuttanut se, että sekä lähettäjä, että vastaanottoja sijaitsivat SEPA-alueella (Single Euro Payments Area). Hetzner on siis saksalainen yritys, jossa sen päätoimipaikkakin sijaitsee.

Tilisiirto käyttäen verkkopalvelua Wise

Wisen käyttöliittymä ei ole niin monimutkainen, että se tarvitsi runsasta selittämistä. Sillä pääsee hyvään alkuun, kun hakee sieltä esille painikkeen "Send money". Koska tuntui merkitykselliseltä voida arvioida, mitä seuraamuksia sillä on, jos tilisiirron tiedoissa on jotain vikaa, vastaanottajan (Hetzner) nimeksi laitettiinkin pankin nimi ja viitetietoihin ei laitettu pelkästään vaadittua Hetzner-asiakastunnusta, vaan sen siihen lisättiin tekstirimpsu "Customer ID:", mutta yhtä nopeasti maksu päätyi käyttöön kuin pankin tilisiirtoa käyttäen.

Maksujen välittäjä Wise otti kymmenen euron tilisiirrosta palvelumaksua 0.41 eur, mikä lienee ihan hyväksyttävissä oleva summa. Hetznerille päätyvä summa on selkeästi esitetty ja omasta verkkopankista voi nähdä, että tililtä on vähentynyt kymmenen euro. Rahaliikenne on tässä tapauksessa kulkenut myös Trustlyn kautta, mistä on se hyöty, että henkilöllisyys varmistetaan pankkitunnuksilla, eikä muuta henkilöllisyyden todistamista tarvita.

Tilisiirto käyttäen oman pankin tilisiirtoa (Nordea)

Hetznerin IBAN-tilinumeron lisäksi tärkeää oikein merkittävää on Hetzner-asiakasnumeron sisällyttäminen viitetietoihin. Wisella tehdystä hienoisesta virheestä saattoi päätellä, että viitetietona oleva asiakasnumero voi sisältää myös hiukan ylimääräistä kuten "Customer ID:" ennen varsinaisesti asiakasnumeroa ja rahasumma päätyy silti sinne minne pitikin. Suositeltavaa kait kuitenkin käyttää viitetiedoissa pelkkää asiakasnumeroa. Nordea-pankki ei ottanut palvelumaksua (taisi sisältyä henkilökohtaiseen palvelupakettiin).

Verkkopankissa tehty tilisiirto ei voisi paljoa helpompi ollakaan. Aivan yhtä helppoa kuin tilisiirrot kotimaassa. Erottuvuuden vuoksi on lähetetty hiukan erilainen summa eli kolme euroa, mikä päätyi kokonaisuudessaan Hetznerin tilille.

Muita maksujenvälityspalveluita ja henkilöllisyyden todistamista

PayPal-yrityksen Xoom-palvelu saattaa olla yhtä käypä kuin Wise. Muita maksujenvälityspalveluita esille seulomalla ovat potentiaalisesti käyttökelpoiseksi päässeet myös Azimo, Instarem, Revolut, MoneyGram ja transferGo. Jonkinlaisia maarajoituksia lähettäjän sijainnin suhteen on sellaisilla maksujenvälityspalveluilla kuin Western Union, SendMoney24, GlobalWebPay ja Ria. Skrill olisi muuten kelpoisan oloinen, mutta tätä kirjoittaessa yksityishenkilöt eivät voi lähettää sillä maksuja yrityksille.

Joissakin näistä palveluista ei pääse tekemään paljon mitään ennen kuin todistanut henkilöllisyytensä jollain hiukan vaivalloisella tavalla ja mahdollisesti ottanut vielä selfienkin, sekä todistanut osoitteensa skannaamalla esim. jonkin kirjepostin mukana tulleen laskun. Kokeillun Wise-palvelun kohdalla voi käyttää Trustlya maksutapana, jolloin pankkitunnuksien lisäksi ei muuta henkilöllisyyden todistamista tarvitsekaan. Wise-palvelun verkkosivuilla on sanottu Trustlysta, että se on käytettävissä Virossa, Suomessa, Espanjassa, Puolassa, Ruotsissa ja Tanskassa.

Asiakasta voi hyvinkin kiinnostaa kokeilla, minkälaisia käyttäjämääriä julkaisusovellus kestää ja tällainen ns. kuormitustestaus on hyväksyttävää, kunhan se ei jatku tuntikausia. Minuuttikin joidenkin teoksen kirjoitusten latailua automatisoidusti esim. jollain verkossa käytettävissä olevalla kuormitustestaus-sovelluksella riittää hyvän tuntuman saamiseen. Yhden palvelimen systeemissä pitäisi yhtä kirjoitusta pystyä latailemaan perusresursseilla esim. 8000 krt minuutissa vasteajalla 70 ms tjs. Ottaen huomioon, että esim. useimmat internetin blogikirjoitukset saavat vaikkapa vain muutama sataa lukukertaa kuukaudessa, pitäisi perusresurssien riittää "ihan hyvin" moniin tarkoituksiin. Julkisten teosten kuvat latautuvat aina CDN-palvelun kautta, jos CDN-palveluun on muistettu ladata käyttöaikaa.

Eräs asiakkaan pikaisesti käytettävissä oleva keino vähentää julkaisusovellukseen kohdistuvaa kuormitusta on lisätä teoskohtaisia välimuistitusaikoja, joka on vakiona 5 sekuntia. Tämä välimuistitus tarkoittaa sitä, että esim. yhtä teoksen kirjoitusta ei generoida jokaisella sivulatauksella erikseen, vaan viimeisin generointi tallennetaan palvelimella tiedostoon, jota hyödynnetään esim. seuraavien viiden sekunnin ajan tai sen verran, mitä sen on säädetty olevan. Se voi olla kaksi tuntiakin. Kirjoituksen ja muiden teoksen osien generointi on aina palvelimen prosessoria kohtalaisen paljon kuormittava toimenpide ja ainahan on se mahdollisuus, että sivunlatauspyyntöjä tulee paljon kerralla. Generoidun teoksen osan tiedostosta lukeminen on tähän verrattuna erittäin vähän palvelimen resursseja kuormittavaa.

Palvelinlaitteiden ja ohjelmistojen kuormittumiseen liittyvät säädöt eivät tule täysin hyödynnetyiksi, jos sisääntulevat signaalit ensinnä vastaanottava Linux-palvelin on konfiguroitu outbound-kaistan osalta tiedonsiirtoa runsaasti rajoittavaksi. Tämä tehdään Linuxin tc-käskyllä (sanoista "traffic control") ja syynä sen käytölle voisi olla esim. oletettu uhka sille, että botteja olisi tahallaan ohjelmoitu kuluttamaa kuukausittaisen tiedonsiirron määrää siten, että ne latailevat pitkän ajanjakson aikana erittäin monia kertoja kohtalaisia määriä erilaista sisältöä kuten kuvia ja teosten sivuja. Sitä ei ehkä mielellään maksaisi useita satoja euroja ylimääräistä oletetun esim. kympin sijaan. Käytännössä helpoimmalla pääsee, kun varautuu maksamaan kolme kertaa oletettua enemmän pitämällä kaistaa vain hiukan rajoitettuna ja huomaa toivottavasti toistuvastai, ettei mitään pahaa tapahtunutkaan.

Normaalisti datakeskus-palveluiden tarjoaja Hetzner alkaisi laskuttamaan julkaisusovelluksen palvelimilta ulospäin suuntautuvasta datasta sen jälkeen, kun datan siirtomäärät ylittäisivät 20 TB. Tämä määrä eli 20 000 GB on runsaasti, jos kyse on vähäliikenteisestä julkaisusovelluksen instanssista. Varmuuden vuoksi julkaisusovelluksen palvelimiin tehdään asiakaskohtaisesti sellainen täydentävä rajoitus, mikä estää kuukausittaisten datansiirtomäärien nousemisen yli tuon 20 TB. Tämä tapahtuu rajoittamalla palvelimen virtuaalisen verkkokortin siirtonopeutta tasoon 60 mbps eli 7.5 MB/s (ks. laskelma: https://www.wolframalpha.com/input/?i=60Mbps+in+TB%2Fmo... Määritetyn datansiirtorajan yli menevää osuutta kustannuksista nimitetään englanniksi "overage costs" ja palvelimelta ulospäin suuntautuvasta datasta käytetään joko nimitystä "egress data" tai "outbound data". Siitä voidaan sopia erikseen, josko tämä keinotekoinen rajoite poistettaisiin, mutta se vaatii samalla sopimaan datansiirtokustannuksista maksamisen käytännöistä. Jos datakeskus-palveluiden tarjoajana on jokin muu kuin Hetzner tai 20 TB ei muuten ole overage costs -maksun rajana, siitä mainitaan erikseen ennen palvelusopimuksen tekemistä.

Jos kävijämäärät lisääntyvät yht'äkkiä voi siitä aiheutua vaikeuksia päästä kirjautumaan käyttäjätunnuksella tai tehdä minkäänlaista esim. editoivaa, koska kuormituksen vuoksi kaikki olisi kovin hidasta. Kirjoituksen "Julkaisusovelluksen verkkotopologian muuttaminen" kuvat antanevat muutaman idean vaihtoehdoista verkkotopologian muuttamiseen sellaiseksi, että saavutettaisiin paremmin ulkoista kuormitusta. Muina palvelunlaatua parantavina keinoina ovat yksinkertaisesti vCPU:n lisääminen virtuaalipalvelimien tapauksessa (lisää prosessin käyttöaikaa yhteiskäytössä olevalle palvelinlaitteen prosessorille) ja vaihtaminen dedikoitujen palvelimien käyttöön. Näistä hiukan lisätietoja ohjeiston kirjoituksessa "Julkaisupalvelua käyttämään".

CDN-palvelun käyttöönotto on suht helppoa. Viidennän kohdan pääsee tekemään valmiiksi sitten, kun julkaisusovellus on asennettu ja siihen voidaan sisäänkirjautua. Vaihtoehtona on, että käyttäjätunnuksen rekisteröinti ja esikonfigurointi tehdään asiakkaan puolesta, minkä jälkeen käyttäjätunnukselle vaihdettaisiin asiakkaan sähköpostiosoite.

1. käyttäjätunnuksen rekisteröinti BunnyCDN:nään
2. pull zone -tunnisteen luominen (ks. kuva 1)
3. muiden tärkeiden pull zone -asetusten säätäminen (ks. kuva 2)
4. käyttöajan lataaminen rahalla (esim. PayPal-maksuna) viimeistään 14 päivän kuluttua (BunnyCDN:n kokeiluaika päättyy silloin)
5. laitetaan CDN-osoite [1] julkaisusovelluksen asetuksiin sekä julkaisusovelluksen instanssin laajuisesti, että käyttäjäkohtaisesti (Managing-käyttöliittymässä ja käyttäjäasetuksissa)

Pull zone -termi on selitetty tarkemmin BunnyCDN:n ohjeissa: https://support.bunny.net/hc/en-us/articles/207790269-How-to-create...

SSL-sertifikaatti

Julkaisusovellusta selaimessa käytettäessä sen verkko-osoitteen alussa on joko HTTPS tai HTTP. Ensin mainittu näistä tarkoittaa, että yhteys käyttäjän selaimelta julkaisusovelluksen käyttämille palvelimille asti on suojattu eli tietoliikennettä ei käytännössä voisi salakuunnella ja tallettaa esim. julkisissa WiFi-verkoissa. Ainakaan verkkoa tarkkailemalla, siis. Käyttäjän päätelaitteiden tietoturva on sitten asia erikseen. Yhteyden suojaamiseksi tarvitaan SSL-sertifikaatti, josta käytetään myös nimityksiä SSL-varmenne (Secure Sockets Layer) ja TLS-varmenne (Transport Layer Security).

Hinnoittelu: SSL-sertifikaateilla on vuosihinnoittelu, eikä ominaisuuksien puolesta ole välttämättä tarpeen hankkia sen kummempaa kuin PositiveSSL, jota saa monista paikoin (esim. Namecheap) ja hyvässä lykyssä puoleen hintaan samalta taholta, jolta ostaa verkkotunnuksenkin. PositiveSSL:n vuosimaksu on alle kymmenen euroa ja se ostetaan aina tietylle verkkotunnukselle tai aliverkkotunnukselle, eikä sitä voi vaihtaa myöhemmin. Viisi vuotta kerrallaan maksaen hintana olisi viitisen euroa per vuosi. Ostettua sertifikaattia ei voi siirtää myyjätaholta toiselle.

Erityistä mainittavaa: Tavallisella HTTP-yhteydellä kaikki samaan lähiverkkoon liittyneet voivat ehkä hyvinkin helposti tallentaa muiden kyseisessä lähiverkossa aiheuttamaa tietoverkkoliikennettä tarkoitukseen soveltuvalla ohjelmalla (esim. Wireshark), jos mitään erikoisempia suojauksia tai tietoliikenteen salauksia ei ole käytössä. Tai ehkäpä kyse olisi jonkin ison organisaation kuten jonkin oppilaitoksen verkon käyttämisestä julkaisusovellukseen kirjautumiseen tai siinä julkaistujen teoksien lukemiseen, jolloin on paljolti tuon organisaation IT-osaston osaavuudesta kiinni, kuinka helppoa siihen verkkoon liittyneiden käyttäjien on seurailla toistensa toimintaa kyseisessä verkossa. Organisaation ulkopuolelta salakuuntelu olisi vaikeampaa, jos kyse ei olisi langattomasta verkosta, mutta toisaalta julkaisusovelluksen selain- ja palvelinosien kommunikoidessa keskenään, ei tietoliikenteen salaamiseksi oikeastaan riitä se, että alkumatka eli se missä selaamiseen käytetty laite fyysisesti sijaitsee, on jonkin organisaation tarjoamassa suojassa, koska sieltä voi olla pitkät fyysiset ja virtuaaliset matkat sinnepäin internetiä, missä julkaisusovelluksen käyttämä palvelin sijaitsee. Siihen välille mahtuu monenlaista reitityskohtaa ja eri verkkojen osia, joissa tieto kulkisi pelkkää HTTP:tä käyttäessä salaamattomana.

Käyttöönotto: SSL-sertifikaatin käyttöönotto koostuu sarjasta tehtäviä, joiden tuloksena saadaan lopullinen SSL-sertifikaatti palvelimelle kopioitavana plaintext-tiedostona. Julkaisusovelluksen asiakas pystyy tekemään kaikki seuraavat vaiheet itse, jos keskittyy jokaiseen osatehtävään riittävällä huolellisuudella. Jos julkaisusovelluksen myyjä suorittaa SSL-sertikaatin käyttöönoton kaikkine vaiheineen, täytyisi jälleen siirrellä rahaa PayPal-maksuna ja lopuksi asiakas saattaisi haluta päätyä ostetun SSL-sertifikaatin omistajaksi, mikä vaatii oikeuksien siirtämistä taholta toiselle. Tämä SSL-sertifikaatin ostaminen ja kaikki siihen liittyvät vaiheet ovat tarpeen vain siinä tapauksessa, että asiakkaan käyttöön otetaan jokin muu julkaisusovelluksen verkko-osoite kuin se mistä tullaan mahdollisesti sopineeksi asiakkaaksi tulemisen yhteydessä.

• rekisteröinti kauppapaikkaan (saattaa olla sama kuin verkkotunnusta ostaessa kuten Namecheap)
• SSL-sertifikaatin ostaminen (halvin eli PositiveSSL riittää)
• SSL-sertifikaatin allekirjoitusprosessin käynnistäminen generoimalla CSR-koodi (https://decoder.link/csr_generator)
• samalla generoituvan private keyn kopioiminen itselleen talteen (ks. kuva 1)
• CSR-koodin (Certificate Signing Request) kopioiminen tietokenttään
• DCV-validointimetodin (Domain Control Validation) valitseminen (käytettävä sähköpostivalidointia)
• odotellaan viestiä sähköpostiin (ks. kuva 2)
• klikataan validointiviestin linkkiä ja annetaan kysyttäessä validointikoodi (mukana samaisessa sähköpostissa)
• odotellaan toista viestiä sähköpostiin (ks. kuva 3)
• otetaan SSL-sertifikaatin sisältävästä viestistä zip-päätteinen liitetiedosto talteen ja puretaan zip-paketin sisältö johonkin hakemistoon (sisältää .crt- ja .ca-bundle -päätteiset tiedostot)
• yhdistetään zip-paketin tiedostojen sisältö private keyn kanssa (luodaan uusi vapaasti nimettävä tiedosto, jolle tiedostopääte .pem, johon tulee ensinnä .crt-tiedoston sisältö, toisena .ca-bundle -päätteisen tiedoston sisältö ja kolmantena private key)
• lähetetään .pem -tiedosto julkaisusovelluksen tarjoajalle

Kohdan 9 jälkeen voidaan lähettää sähköpostiin saapunut zip-tiedosto julkaisusovelluksen ylläpitäjälle ja skipata loput vaiheet, mutta se ei pelkästään riitä, sillä generoitu private key tarvitaan silti. Private keyn voi sisällyttää suoraan sähköpostiin tekstiksi, sillä base64-koodattuna se ei pääse vääristymään sähköpostin internetissä kulkiessa.

CSR-koodista on lisätietoa esim. täällä: https://www.namecheap.com/support/knowledgebase/article.aspx/337/67...

DCV-validointimetodista on lisätietoa esim. täällä: https://www.namecheap.com/support/knowledgebase/article.aspx/9637/6... (olennaisia ainoastaan alaotsikoiden "Receive an email" ja "Changing DCV methods" alla olevat tekstit ja kuvat)

Sitten kun SSL-sertifikaatti on lopulta asennettu käyttöön, sen toimivuuden voi tarkistaa monilla vaihtoehtoisilla sertifikaatin tarkistamiseen tarkoitetuilla verkkopalveluilla.

--

VPN-yhteys

Jos SSL-sertifikaatin käyttöönoton kanssa näpräämiseen ei kerta kaikkiaan löydä motivaatiota, voi käyttäjätunnuksellinen käyttäjä vähintään jossain määrin kätkeä muilta sen tiedon, milloin, missä ja miten hän julkaisusovellusta käyttää. Tällaiseen tarkoitukseen voi käyttää monien erilaisten päätelaitteiden ja käyttöjärjestelmien käyttöön helposti ostettavaa ja asennettavaa VPN-yhteyttä (Virtual Private Network), jolloin kaiken internetliikenteen voi suojata päätelaitteelta siihen välittäjän asemassa toimivaan palvelimeen asti, joka sitten varsinaiset yhteydenotot julkaisusovelluksen palvelimille tekee. VPN-yhteyden jälkimmäisen puoliskon yhteys ei muutu salatuksi itsestään, jos palvelin ei ole asetettu sellaista hyödyntämään eli jos palvelimella ei ole SSL-sertifikaattia käytössä.

Hinnoittelu: Usean vuoden sopimuksella muutama euro per kk, kuukauden mittaisille laskutusjaksoilla enemmän. Maksetaan suoraan VPN-palvelun tarjoajalle.

Erityistä mainittavaa: Julkaisusovelluksen teosten lukijoiden kannalta huomioitavaa on, että joissakin organisaatioissa käytetyt selaimet voivat olla konfiguroitu siten, että niillä voi ottaa yhteyttä vain sellaisiin sivustoihin, joihin otetaan yhteyttä käyttämällä HTTPS-protokollaa (esim. osoitteella https://example.com). HTTPS:sää varten tarvitaan SSL-sertifikaattia ja sellaisen puuttuessa julkaisusovelluksen käyttämältä palvelimelta, voi käyttäjän selain viestiä hyvinkin visuaalisesti siitä, että käydyllä verkkosivulla ei ole suojausta käytössään. Eli VPN olisi hyödyttämässä vain sitä käyttäjätunnuksellista käyttäjää, joka VPN-yhteyttä käyttää.