(This is only relevant for customers who want something more specific in addition to the features of Symantec Basic SSL Certificate that is installed for free. This is also an example of how simple tasks can become more complicated.)

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 one meant for testing purposes (defined on the first phases of becoming a customer).

1. registration to a marketplace (may be the same as when buying a domain name such as Namecheap)
2. purchase of an SSL certificate (the cheapest one, PositiveSSL, is sufficient)
3. starting the SSL certificate signing process by generating a CSR code (https://decoder.link/csr_generator)
4. copying the private key that gets generated at the same time (see image 1)
5. copying the CSR (Certificate Signing Request) code into the text field
6. select the Domain Control Validation (DCV) method (email validation must be chosen)
7. wait for a message to be received by email (see image 2)
8. click on the link in the validation message and enter the validation code when prompted (included in the same email)
9. wait for the second message to be received by email (see image 3)
10. extract the contents of the attached zip package from the email containing the SSL certificate to a directory (includes .crt and .ca-bundle files)
11. join the contents of the extracted files with the private key (create a new freely-named file with a .pem extension, containing first the contents of the .crt file, second the contents of the .ca-bundle file and third the private key)
12. send the .pem file to the publishing application provider

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/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)