When using a publishing application in a browser, the web address will start with either HTTPS or HTTP. First one of these mean that the connection from the user's browser to the servers used by the publishing application is secure, i.e. the traffic could not, according to general consensus, be intercepted and captured, e.g. on public WiFi networks. At least by monitoring the network, that is. The security of user devices is a separate issue. To protect the connection, an SSL certificate is needed, also known as Secure Sockets Layer (SSL) and Transport Layer Security (TLS).
Pricing: SSL certificates are priced on an annual basis, and it is not necessarily necessary to buy anything more feature-rich than PositiveSSL, which is available from many places (e.g. Namecheap) and with some luck for half the price from the same company from which you can buy a domain name. PositiveSSL costs less than 10 eur per year and is always purchased for a specific domain or subdomain and cannot be changed later. If you pay for five years at a time, the price would be around 5 eur per year. Once purchased, the certificate cannot be transferred from one vendor to another.
Notice: With a standard HTTP connection, all those connected to the same local area network may very well be able to capture the network traffic generated by others on that local area network using appropriate software (e.g. Wireshark), provided that no fancy security or encryption is in place. Or it could be that large organisation's such as an educational institution's network is used to log on to the publishing application or to read published works, in which case the ease with which users connected to that network can monitor each other's activity on that network depends largely on the competence of the IT department of that organisation. From outside the organisation, eavesdropping would be more difficult if it were not a wireless network, but on the other hand, when the browser and server parts of a publishing application communicate with each other, it is not really sufficient for the communication to be encrypted that the initial path, i.e. where the device used for browsing is physically located, is protected by an organisation, since there may be long physical and virtual distances from there to the server used by publishing application. In between, there are many different routing points and different parts of the network where data would travel unencrypted.
Deployment: SSL certificate deployment consists of a series of tasks that result in the final SSL certificate as a plaintext file to be copied to the server. The customer of the publishing application can perform all of the following steps, provided that the customer focuses on each of the steps with sufficient care. If the provider of the publishing application performs all the steps to deploy the SSL certificate, money would again have to be transferred as a PayPal payment and, finally, the customer might want to end up as the owner of the purchased SSL certificate, which requires a transfer of rights from one party to another. The purchase of an SSL certificate and all the steps involved are only necessary if the customer uses a different web address for the publishing application than, for example, xyx.testingkwstories.net.
After step 9, you can send the emailed zip file to the publication application provider and skip the rest of the steps, but that alone is not enough, as the generated private key is still needed. The private key can be included directly in the email as text, as it is base64 encoded and cannot be distorted while the email travels over the internet.
For more information on the CSR code, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/337/67...
For more information on the DCV validation method, see for example: 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)
Once the SSL certificate is finally installed, its functionality can be checked with any of the online certificate verification services.
If there is simply no motivation to fiddle with SSL certificate deployment, a user with a user account can at least to some extent hide from others the information about when, where and how the publishing application is used. For this purpose, a VPN (Virtual Private Network) connection, which can be easily purchased and installed for use with a wide range of devices and operating systems, can be used to protect all internet traffic from a device to the server acting as an intermediary, which then makes the actual connections to the servers of the publishing application. The second half of the VPN connection will not become encrypted on its own if the server is not set up to use it, i.e. if the server does not have an SSL certificate in place.
Pricing: Paid directly to the VPN service provider.
Notice: Some browsers used in some organisations may be configured to allow access only to sites that are accessed using the HTTPS protocol (e.g. https://example.com). HTTPS requires an SSL certificate, and in the absence of one from the server used by the publishing application, the user's browser may give a very visual indication that the web page being visited is not secure. In other words, the VPN would only benefit the authenticated user who is using the VPN connection.