Until the day TLS 1.3 becomes widely supported, web servers must rely on a fallback to TLS 1.2 with correctly configured server directives and strong cipher suites. Pick the wrong settings, and you declare an open season on your server.
As browser makers continue their push for HTTPS for even the tiniest of websites and mobile applications are becoming the target of MITM (man-in-the-middle) attacks, cloud developers and administrators are scrambling to find affordable SSL certificates for their deployments that can live up to the demands of the cloud era. Enter Letsencrypt, a new Certificate Authority that is open, fully automated, and free to use, with an almost unprecedented, generous allotment of 100 host names per certificate. Currently ending its public beta phase and expected to be released soon, Letsencrypt holds the promise of a worry-free, fully encrypted web 3.0. Cloud Insidr lifts the veil off of Letsencrypt’s setup, configuration, its few surprises and hidden gems.
In order to transfer files from one server to another you can use Unix tools such as rsync with key pairs. Setting up the connection is rather easy once you know how to do it.
How keys work in public key cryptography
In public key cryptography, two text strings–the keys: one private key and one public key–can be compared against one another using a cryptographic algorithm. If the verification succeeds, access is granted. Think of the public key as the lock on a door that is technically available to everyone but can only be opened using a valid key (the one you may carry in your pocket).
In public key cryptography, your private key is like the master key of an apartment house: it can open all the locks on any door anywhere. Much like in the real world, you can create several copies of your private key (the universal master key) and use it on different systems (on different apartment houses) and much like in the real world you would not want to do that unless you have a valid reason.
In order for the source host (ec-instance-01) to be able to connect to the target host (ec-instance-02), create a key pair in the .ssh directory on the source host and append only(!) the public key from this pair to the authorized_keys file of your user on the destination host. Here is a detailed step-by-step guide on how to configure the two hosts.