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 file to be copied to the server. Here's one kind of process to do it:

1. Customer buys and pays a SSL-certificate (e.g. PositiveSSL), after which validation, activation and deployement is required. Before these phases certificate is in "pending" state.
2. For validation and activation a base64-coded CSR is required (Certificate Signing Request), which can be genereated e.g. using https://decoder.link/csr_generator. After generating it a private key is shown, which must be copied and saved at least momentarily as it needed in the last phases, meaning the one where the certificate is installed on the server. As a very relevant question is also, for which domain or subdomain the SSL-certificate is meant to. That is not asked in the buying phase as it can be decided later.
3. On the form which is used to initialize validation and activation of the certificate, there's also a question about what DCV (Domain Control Validation) should be used and answer to that is in this case "Email validation". For that to work, a new email probably have to be created on the domain for which the certificate is meant to, because validation email can not be sent to any email address. Allowed ones are those, which are given to choose from like e.g. admin@domain.com, webmaster@domain.com, hostmaster@domain.com tai postmaster@domain.com. Email address that is an answer to the question "SSL files recipient", may be any email address (the SSL-certificate will be sent to that address).
4. Validation email might arrive after a few minutes or after a few hours, but probably "rather soon". It will ask to click on the link in the validation message and enter the validation code when prompted (included in the same email).
5. Finally, thus after not so many phases, customer receives ready SSL-certificate probably in a zip package, which contains files having .crt- and .ca-bundle extensions. These must be sent to the publishing application provider together with the private key (they are required for creating a .pem file that needs to be installed on the server). That will end the process of getting and installing a SSL-certificate (until it become time renew it).

For more information on the CSR code, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/337/67/what-is-a-certificate-signing-request-csr/

For more information on the DCV validation method, see for example: 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)