On the open Internet, any communication between a client and a server should be encrypted to prevent evil attackers from viewing data, modifying them or (if the transferred data are credentials like username and password) impersonating a user.
For this purpose, the Transport Layer Security (TLS) protocol is usually used. But the protocol requires the server side to have a so called digital certificate to prove its identity.
The SDI4Apps platform can be deployed to any Infrastructure-as-a-Service cloud as a Virtual Machine (VM) with a set of preinstalled geospatial software. The set includes the Liferay portal server, which holds user accounts. When users log in, the communication should be encrypted for the reasons stated above. This presents a challenge, as the VM gets a random IP address mapped to a random DNS name, and we need a digital certificate for that random name.
We investigated the Let’s Encrypt certification authority that issues digital certificates for free by just calling a script. The command is
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt cd /opt/letsencrypt ./letsencrypt-auto --apache --email john@doe.com --agree-tos --no-redirect -d $(hostname -f)
This seemed very promising, but experiments found intractable problems on real-world clouds:
- on the Amazon EC2 cloud, the assigned IP addresses are mapped to the domain compute.amazonaws.com which is blacklisted by the Let’s Encrypt CA
- on the Google CE cloud, it is possible to obtain a certificate from Let’s Encrypt, but browsers refuse to connect to a web server with such a certificate, because Google used Public Key Pinning to prevent usage of certificates for names mapped to the assigned IP addresses
- on the Masaryk University’s community cloud, it is possible to obtain certificates from Let’s Encrypt, but there is a limit of at most 5 certificates per 7 days, which gets exhausted rather quickly
The limit of 5 certificates per 7 days applies to a second-level DNS domain (like cerit-sc.cz), and it can be lifted by registering the domain at the Public Suffix List, but the problems encountered at Amazon and Google clouds cannot be solved by writing a script that gets executed when the VM starts, they need a manual intervention.
So the solution seems to be to automatically generate a self-signed certificate using the commands
HOSTNAME=$(hostname -f) mkdir -p /etc/apache2/ssl openssl req -x509 -newkey rsa:2048 -keyout /etc/apache2/ssl/key.pem -out /etc/apache2/ssl/cert.pem -days 3650 -nodes -subj "/CN=$HOSTNAME"
which ensures that the communication between a browser and the server is encrypted, but which is not trusted by web browsers as it is self-signed.
The server needs to be assigned a stable DNS name from a domain that is controlled by the deployer, and a certificate can be then manually obtained for the stable name from any respectable certification authority, including the Let’s Encrypt CA.
