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 tiedostona. SSL-sertifikaatin eräs hankintaprosessi (omatoimisesti ja sähköpostivahvistuksella) olisi seuraavanlainen:

1. Asiakas ostaa ja maksaa SSL-sertifikaatin (esim. PositiveSSL), minkä jälkeen tarvitaan vielä validointi, aktivointi ja käyttöönotto. Ennen näitä muita vaiheita sertifikaatti on "pending"-tilassa.
2. Validointia ja aktivointia varten tarvitaan base64-koodattu CSR-pyyntö (Certificate Signing Request), minkä voi luoda esim. käyttäen https://decoder.link/csr_generator. Sen luomisen jälkeen nähtävillä on myös private key, joka täytyy kopioida talteen, koska sitä tarvitaan viimeisessä vaiheessa eli siinä, missä sertifikaatti asennetaan palvelimelle. Oleellisena vastattavana kysymyksenä on myös se, mille verkkotunnukselle tai aliverkkotunnuksella SSL-sertifikaatti on tarkoitettu. Tätä ei siis kysytä vielä ostovaiheessa, vaan se on hetkeä myöhemmin päätettäviä asioita.
3. Lomakkeella tai sen eri osissa, millä validointi ja aktivointi laitetaan aluille, kysytään CSR-pyynnön lisäksi myös DCV-validointimetodia (Domain Control Validation), joksi laitetaan "Email validation". Jotta "Email validation" voisi toimia, sitä varten on todennäköisesti luotava sähköpostitili sille verkkotunnukselle, jolle sertifikaatti on tarkoitettu, sillä validointiviestiä ei voi saada mihin tahansa sähköpostiosoitteeseen. Kelpaavia ovat ne, jotka ovat valittavissa eli oletettavasti ainakin admin@domain.com, webmaster@domain.com, hostmaster@domain.com tai postmaster@domain.com. Samassa yhteydessä kysytään myös "SSL files recipient"-sähköpostiosoitetta eli mihin valmis SSL-sertifikaatti lähetetään.
4. Validointisähköposti saattaa saapua minuuttien tai tuntien viiveellä. Siinä pyydetään menemään sertifikaatteja myöntävän tahon osoittamaan verkko-osoitteeseen ja antamaan siellä olevaan yksinkertaiseen lomakkeeseen validointikoodi, joka on mukana samaisessa sähköpostiviestissä.
5. Lopulta, täten ei niin kovin monien vaiheiden jälkeen, asiakas saa tavalliseen sähköpostiinsa valmiin SSL-sertifikaatin oletettavasti zip-paketissa, joka sisältää .crt- ja .ca-bundle -päätteiset tiedostot. Nämä täytyy lähettää julkaisusovelluksen tarjoajalle yhdessä aiemmassa vaiheessa talteen otetun private keyn kanssa, jotta ne voidaan asentaa ne palvelimelle (tarvitaan .pem-päätteisen tiedoston luomiseen). SSL-sertifikaatin hankinta- ja asennusprosessi päättyy sillä erää siihen (seuraavan kerran hiukan ennen sitä, kun on sertifikaatin uusimisen aika).

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)