Mitä tarvitaan ja miksi

• Virtuaalipalvelin, jotta julkaisusovellus voidaan asentaa käytettäväksi.
• Verkko-osoite, jotta muut tietävät mihin mennä.
• Suojattu yhteys, jotta tieto käyttäjien ja julkaisusovelluksen kulkisi salatusti.
• CDN-palvelu, jotta julkaisusovelluksen toimivuus olisi nopeampaa ja vakaampaa.

Paljonko maksaa

Virtuaalipalvelin. Hyvät ja paljoon riittävät vähimmäisresurssit maksavat n. 8 euroa kuukaudessa. Käytössä on tuntiperusteinen laskutus. Monenlaisia variaatioita palvelinresursseissa ja verkkotopologiassa. Palveluntarjoajana Hetzner, jolla palvelinkeskus esim. Suomessa.

Verkko-osoite. Tämä on tarkoitus hankkia Hetzneriltä ottamalta käyttöön sen webhosting-palvelupaketti, minkä kuukausimaksuun, joka on vähimmillään n. 2 euroa, sisältyy yksi ilmainen verkko-osoite (olettaen päätteenä olevan jokin tavanomainen kuten .net, .com tai .org). Tähän palvelupakettiin sisältyy n. 10 euron aloitusmaksu.

Suojattu yhteys. Hetzterin webhosting-palvelupakettiin sisältyy myös ilmainen suojattu yhteys Symantec Basic SSL Certificaten muodossa.

CDN-palvelu. Tätä varten rekisteröidään erillinen käyttäjätunnus Bunny CDN:ään. Sen maksuksi voi riittää pitkäksi aikaa muutaman euron ennakkomaksu. Jos tämä ennakkomaksu tulee käytetyksi, julkaisusovellus jatkaa toimintaansa, mutta herkemmin kuormittuvana.

Miten maksaa helpoiten

Sekä Hetznerin ja Bunny CDN:n palveluista on helpointa maksaa ennakkomaksuilla, joka Hetznerin tapauksessa lisää "credit balancea", jota käytetään automaattisesti laskujen maksamiseen.

Asiakkaan ei tarvitse antaa pankkitietojaan julkaisusovelluksen kehittäjälle/myyjälle. Sen sijaan ennakkomaksut suoritetaan siten, että asiakas lähettää ennakkomaksun käyttäen PayPal-rahansiirtopalvelun sisäistä rahansiirtoa, minkä jälkeen kyseinen ennakkomaksu siirretään manuaalisesti kokonaisuudessaan Hetznerin ja Bunny CDN:n suuntaan.

Varsinkin ensivaiheessa käytetään mieluiten PayPal-rahansiirtoa, mutta myöhemmissä vaiheissa Hetznerin ennakkomaksun voi maksaa myös pankin tilisiirtona. Tilisiirtoa tehdessä viitetietoihin laitetaan Hetzner-käyttäjätunnuksen id-koodi, jotta lähetetty rahasumma ohjautuisi oikean käyttäjätunnuksen käyttöön. Bunny CDN:n ennakkomaksua ei välttämättä tarvitse maksaa pitkiin aikoihin ollenkaan tai yleensäkään säännöllisesti, jos sitä ei tule käytetyksi paljoa. Bunny CDN:llä on muitakin palveluita käytettäväksi, joista voi halutessaan maksaa samoilla ennakkomaksuilla.

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.

Hinnoittelusivut

• Hetzner (pilvipalvelut): https://www.hetzner.com/cloud/
• Hetzner (webhosting): https://www.hetzner.com/webhosting/
• Bunny CDN: https://bunny.net/pricing/

Sopimuksien kestot

Hetzner laskuttaa virtuaalipalvelimien käytöstä, vaikka ne olisivat sammuksissa. Jos ne poistaa kokonaan käytöstä ja jättää jäljelle vain käyttäjätunnuksen, laskuttaminen päättyy meneillään olevaan tuntiin.

Hetznerin webhosting-palvelun osalta voi joutua maksamaan vielä yhden seuraavan kuukauden kuukausimaksun riippuen, milloin palvelun keskeytyksen tekee. Tästä lisätietoa sanoin ja kuvin ohjeissa: 30 days to the end of the month

Verkkotunnukset ovat tyypillisesti sellaisia, joita uudistetaan tai ei uudistetaan vuosittain. Hetznerin webhosting-palvelupakettiin sisältyy ilmainen verkkotunnus, jonka vuosimaksu tulee maksetuksi sen aloitus- ja kuukausimaksusta. Hetzneriltä hankittu verkkotunnus on asiakkaan omaisuutta. Jos asiakas päättää webhosting-palvelupaketin käytön, hän voi jatkaa verkkotunnuksen omistamista, maksamalla siitä vuosimaksun Hetznerille tai siirrättää sen toiselle palveluntarjoajalle.

Bunny CDN:n käytön voi lopettaa milloin vain, mutta ei tietenkään ole suotavaa lopettaa sitä silloin, kun kaikki muut olennnaiset ovat vielä käytössä.

Laskutusjaksot

Hetzner laskuttaa palveluistaan kuukausittain, mikä tarkoittaisi erikseen kahtena eri laskuna virtuaalipalvelimesta/-mista ja webhosting-palvelupaketista laskuttamista. Laskujen kuukausittaiset ajankohdat pysyttäytyvät samoina, mutta vaihtelevat Hetznerillä asiakaskohtaisesti. Ensimmäinen maksumuistutus ensimmäisille laskuille 5 päivän kuluttua laskun saapumisesta, seuraavien osalta 10 päivän kuluttua.

Ennakkomaksujen jäädessä maksamatta

Hetznerin tapauksessa ennakkomaksun on tarkoitus kattaa kustannukset seuraavien 30 päivän osalta. Jos alkaa vaikuttaa siltä, että ennakkomaksua saattaa jäädä maksamatta, asiakkaaseen otetaan yhteyttä ja varaudutaan siihen, kaikki asiakkaan hyödyntämät Hetznerin palvelut joudutaan poistamaan käytöstä. Tämä voi tarkoittaa sitä, että virtuaalipalvelin kaikkine tietoineen saatetaan poistaa, eikä niitä sen jälkeen voi enää palauttaa takaisin käyttöön.

Ennakkomaksujen takaisinmaksu

Hetznerin tapauksessa ennakkomaksut voi saada takaisin jäljellä olevan summan osalta (miinus viimeisen laskun loppusumma). 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 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.

Mitä tarkoittaa "overage costs"

Overage costs tarkoittaa "ylimenevän osuuden hinnoittelua". Hetznerin virtuaalipalvelimen osalta se tarkoittaa sitä, että virtuaalipalvelimelta ulospäin suuntautuva dataliikenne on ilmaista 20 teratavuun asti (1000 gigatavua) ja sen jälkeen siitä käydään laskuttamaan ylimenevälle hinnoittelun perusteella, mikä on Hetznerin tapauksessa 1 eur / teratavu. Asiakkaan kanssa sovitaan erikseen, millä dataliikenteen rajoittamisen keinolla varmistetaan, että dataliikenne pysyttäytyy ilmaisen 20 teratavun rajoissa. Riskinä on, että jotkin vilpilliset tahot kuluttavat ilmaisen dataliikenteen määrää bottien avulla.

Vähimmäisresurssit julkaisusovellukselle

Resursseja kuten levytilaa, muistia/tehoa palvelinlaitteeseen/-teisiin on saatavilla pyydettäessä. Vähimmäisresursseina palvelimelle on todettu sopivaksi 8 GB muistia ja 4 vCPU (prosessorin aikasäikeitä), mikä 15.7.2024:n hinnoittelulla tarkoittaa max. kustannuksina 8,04 eur / kk. Tuolloin käytössä on virtuaalipalvelin eli esim. prosessoria käyttää useampikin Hetznerin asiakas. Dedikoitujen eli yhden asiakkaan käyttöön tarkoitettujen palvelimien hinnat ovat kalliimpia. Julkaisusovelluksen voi hajauttaa useille palvelimille, mistä on lisätietoa verkkotopologiasta kertovassa kirjoituksessa.

Vaihtoehtoisten palveluntarjoajien käyttö

Hetznerin tai Bunny CDN:n kanssa ei ole tehty erillisiä sopimuksia, joiden nojalla pitäydyttäisiin juuri niiden käyttäjänä, mutta ne muuten vain hinnoittelultaan, toimivuudeltaan, ominaisuuksiltaan ja kehittymiseltään erinomaisia. Ylläpidettävyyden samankaltaisena pysyvyys on myös tärkeä kriteeri pitäytyä juuri niiden käytössä. Verkkotunnuksen ja SSL-sertifikaatin voi hankkia muualtakin.

Käyttäjätunnuksien hallinta

Hetznerin ja Bunny CDN:n käyttäjätunnuksien hallinta pysyy pelkästään kehittäjätaholla/myyjällä. Tähän ovat syynä mm. niiden hankintaan vaadittu tunnistautuminen henkilöllisyystodistuksella ja riski vääränlaisten konfiguraatioiden tekemiseen. Erilaiset optionaaliset mahdollisuudet voidaan ottaa käyttöön asiakkaan pyynnöstä ilman erillisiä maksuja, jos niiden käyttöönotto ei aiheuta suuresta vaivaa. Hyödyllistä saattaisi olla esim. Hetznerin webhosting-palvelupakettiin sisältyvät sähköpostitilit ja alidomainit, sekä Bunny CDN:n osalta Bunny Storage.

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.

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.

Kirjoitus-sivuilla on käytössä lazy loading -tekniikka mm. kuville ja videoille eli vain ruudulla jo olevan osan ja siitä vielä 1000 pikselin etäisyydellä olevat ladataan näkyville. Myös ladattavien kuvien resoluutionvalinta on optimoitu sellaiseksi, ettei tarpeettomasti ladattaisi liian korkearesoluutioisia kuvia, mikä pätee sekä sivun ensilatauksella, että siinä yhteydessä, kun selainikkunan kokoa muutetaan. Runsaskuvaisilla sivuilla selainikkunan koon muuttaminen voisi herkästi aiheuttaa jopa tuhansia kuvanlatausyrityksiä, jos selainikkunan kokoa muutettaisiin keskeytyksettä esim. minuutin ajan, joten tällaisen varalta vain kuvien asettelu muuntuu selainikkunan koon mukaan ja kuvien resoluutioiden vaihtamisen tarve huomioidaan vain hetkittäin.

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".

(Tässä kerrottu on merkityksellistä vain sellaisille asiakkaille, jotka haluavat ilmaisena asennetun Symantec Basic SSL Certificaten ominaisuuksien lisäksi jotain sitä erityisempää. Tämä on samalla myös esimerkki siitä, miten sinänsä helpoista tehtävistä tulee sitten kuitenkin monimutkaisempia.)

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ä.

1. rekisteröinti kauppapaikkaan (saattaa olla sama kuin verkkotunnusta ostaessa kuten Namecheap)
2. SSL-sertifikaatin ostaminen (halvin eli PositiveSSL riittää)
3. SSL-sertifikaatin allekirjoitusprosessin käynnistäminen generoimalla CSR-koodi (https://decoder.link/csr_generator)
4. samalla generoituvan private keyn kopioiminen itselleen talteen (ks. kuva 1)
5. CSR-koodin (Certificate Signing Request) kopioiminen tietokenttään
6. DCV-validointimetodin (Domain Control Validation) valitseminen (käytettävä sähköpostivalidointia)
7. odotellaan viestiä sähköpostiin (ks. kuva 2)
8. klikataan validointiviestin linkkiä ja annetaan kysyttäessä validointikoodi (mukana samaisessa sähköpostissa)
9. odotellaan toista viestiä sähköpostiin (ks. kuva 3)
10. 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)
11. 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)
12. 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)