(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/what-is-a-certificate-signing-request-csr/

DCV-validointimetodista on lisätietoa esim. täällä: https://www.namecheap.com/support/knowledgebase/article.aspx/9637/68/how-can-i-complete-the-domain-control-validation-dcv-for-my-ssl-certificate/ (olennaisia ainoastaan alaotsikoiden "Receive an email" ja "Changing DCV methods" alla olevat tekstit ja kuvat)