Setting Up a Cloud Server - Part 4 - Transcript.pdf

Setting up a Cloud Server - Part IV
Now comes the world of pain, SSL support. This is actually not too horrible usually but I chose to go with the free lets encrypt option. That might have been a mistake in
retrospect

server.port: 8443
security.require-ssl=true
server.ssl.key-store:/home/builder/keystore.p12
server.ssl.key-store-password: password
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
application.properties
✦ We configure the path to the keystore, notice that
setting this will break running locally so you might
want to comment this out
© Codename One 2017 all rights reserved
In the IDE on our development machine lets open the application.properties and set several important variables. Notice that I will need to comment out these values
when running locally since I can’t get SSL when running locally. The server must use SSL for everything as iOS won’t allow regular HTTP connections

To do this I’ll define the server port to 8443 and require SSL. The next few lines point at the keystore file, password and alias. We’ll configure all of these values soon

scp ~/dev/AppBackendServer/target/
AppBackendServer-0.0.1-SNAPSHOT.jar
builder@ip.of.remote.server:/home/builder
From Desktop
✦ Copy the updated app to the server
I’ll need to redeploy the updated server with SSL setting by copying it to the server

$mv AppBackendServer-0.0.1-SNAPSHOT.jar
AppBackendServer.jar
Commands
✦ Replace the previous server version
And obviously I’ll need to do this line again too to move the uploaded file to replace the existing backend server.

DNS
build.majimob.com
First we need to setup DNS for the server, assuming you already registered a domain setting the “A Record” to point at the ip address of your server gives it a name. You
can’t apply https to an ip address and it’s not a good idea in the long run as it might pose a problem with scaling or migrating.

Lets Encrypt
✦ Normally certificate authorities work by verifying who
you are via phone, Duns Number etc.
✦ Lets encrypt allows anyone to prove they own a
domain and get a 90 day certificate
✦ 90 Days is painfully short but since the process is
automated & free the assumption is you won’t notice
✦ JDK 8u101 added Lets Encrypt, if you have an older
version you will need to upgrade or you will get an
exception…
Lets for a second stop and explain how HTTPS works. The server sends a certificate which verifies the identity of the server (e.g. this really is build.majimob.com) and to
prove that certificate it is signed by a “signing authority”. This signing authority is a company we trust to verify that identity. In the past signing authorities literally looked
you up thru DUNS numbers which is a horrible thing I don’t want to go into right now. That way they could verify your identity.

Lets encrypt was formed to allow everyone to get a valid SSL certificate for free. It does that by automating the process completely and the trick is composed of two
pieces. The first is an application you run on your server to verify that this is the right server, the second trick is the short lifetime of a certificate. Only 90 days. Even if an
exploit exists it will expire in 90 days naturally.

Normally certificates last a year or two and it’s really painful to replace them. The 90 day time is horribly short and the reason it’s so short is so we would be forced to
automate the process completely. That means our server should request a new certificate on its own without any action from us. That’s actually pretty cool, it would
mean the certificate will always be renewed and current without any work from us once we do the actual work.

One caveat for Java developers is this. In order to recognize a certificate authority the root certificate should be embedded into browsers and the JDK itself. Most
devices/browsers etc. already recognize lets encrypt but the JDK only added it in update 8u101 which is pretty late in the game. That might mean you will need to update
your JDK to access the secure site.

Lets Encrypt - On Spring Boot
✦ Sucks…
✦ Spring Boot makes a lot of things seamless but
doesn’t do it for Lets Encrypt
✦ This might change in the future but this is what I
had to do to get it to work…
So lets get this oﬀ the bat. I really regretted picking lets encrypt as I worked thru the process. It sucks on spring boot. The automation doesn’t work out of the box and I
needed to do so much wizardry it’s amazing… I don’t understand why the guys at Spring or Tomcat didn’t implement builtin support for this out of the box.

I hope they will add it in an update but I haven’t seen anything so far, I seriously hope the rest of this module becomes out of date.

#yum install epel-release
Commands
✦ Install additional 3rd party repository for packages
We start by installing some packages required by lets encrypt, this is pretty much the instructions you can find online to do that. This isn’t a smooth experience in part
because of the newness of lets encrypt. The first thing we install isn’t so much a thing as it is a 3rd party repository to look in for additional packages

#yum -y install yum-utils
Commands
✦ Install additional utilities to fetch lets encrypt tool
Next we install some utilities that allow us use the config manager in the next step

#yum-config-manager --enable rhui-
REGION-rhel-server-extras rhui-REGION-
rhel-server-optional
Commands
✦ Setup configuration for additional region required
by lets encrypt
I honestly have no idea why the hell this is needed, but it’s part of the setup instructions so I went along with it

#yum install certbot
Commands
✦ The lets encrypt command line tool to fetch the
certificates
The certbot is a command line tool that allows us to renew certificates automatically. Certificate Robot - got it…

#service AppBackendServer stop
Commands
✦ We run lets encrypt in sever mode so it opens it’s
own server. We need to stop our server so it can
bind to the ports
We need to stop the server if it’s running. The reason for this is clear when we understand how lets encrypt works. It can integrate with some servers but not with spring
boot. So the alternative is to let it spin its own server on port 443 which we would normally need. So we need to shut down the server while we renew the certificate.

#certbot certonly --standalone -d
build.majimob.com -d build.majimob.com
--tls-sni-01-port 8443 --http-01-port
8080
Commands
✦ Runs a server and verifies your domain against lets
encrypt then generates the certificate into place
✦ Replace build.majimob.com with your domain
✦ Notice the ports argument so it will work with the IP
Tables change
Now that the server is oﬀ we can launch the certbot command which fetches a certificate from the lets encrypt service automatically. The command includes several
arguments so lets review the important ones. —standalone means we’ll be using the standalone server and can’t use integrations to one of the existing supported
servers. -d passed the domain name that we want the certificate for which needs to be the same one associated with the DNS from before. The next two arguments
represent the actual ports used for the servers. Notice that port 80 and 443 will be used internally but since we redirect those to diﬀerent local ports with the iptables
setting we need to indicate the real local ports to use.  
Running this one command should generate the certificate but it doesn’t end there…

openssl pkcs12 -export -in /etc/letsencrypt/live/
build.majimob.com/fullchain.pem -inkey /etc/
letsencrypt/live/build.majimob.com/privkey.pem -out
/home/builder/keystore.p12 -name tomcat -CAfile  
/etc/letsencrypt/live/build.majimob.com/chain.pem 
-caname root
Commands
✦ Converts the certificate to the keystore format used
by Java
✦ Notice the paths include the majimob domain so you
will need to fix those…
This is another big obtuse command. Lets encrypt generates a certificate and saves it using a pem format which we can’t use from Java. We can use this openssl
command to convert the pem file saved in the /etc/letsencrypt directory to the keystore format we need.

#chown builder /home/builder/keystore.p12
Commands
✦ The file was created under root, we need to
change it’s ownership to the right user
We ran that command as root so I’m using the chown command to change the ownership of the file from root to builder. This is generally good practice for files within the
user directory. It would have probably been a better idea to just run the openssl command as builder

#service AppBackendServer start
Commands
✦ Server can go back up, https should work now
for your domain!
Now that this is done I can relaunch the backend server and https should work as expected. But there is still one thing missing

Setting Up a Cloud Server - Part 4 - Transcript.pdf

Recommended

Recommended

More Related Content

Similar to Setting Up a Cloud Server - Part 4 - Transcript.pdf

Similar to Setting Up a Cloud Server - Part 4 - Transcript.pdf (20)

More from ShaiAlmog1

More from ShaiAlmog1 (20)

Recently uploaded

Recently uploaded (20)

Setting Up a Cloud Server - Part 4 - Transcript.pdf