We are using plain HTTP. We need to be using transport encryption to protect the customer's details as they are travelling over the network. This is even more important since we are using Basic Access Authentication (or would be if you implemented the authentication bonus task), which means our authentication token is susceptible to hijacking via network sniffing.

Using the Linux file manager, find your project's main resource folder. It will be in your project's folder in the <> subfolder. This is the folder that should contain the logback.xml file, and the recently created application.conf file.

Right click the background of the file manager and select <

openssl req -newkey rsa:4096 -x509 -nodes -days 365 -keyout key.pem -out cert.pem -subj '/CN=shopping'

All we need to do to get our Jooby server to use this statement is to use Jooby's application configuration file to tell it where to find the certificate.

Run the following command in the same terminal:

mousepad application.conf

Add the following to the text editor that appears, below the existing text that is in the file:

application.securePort = 8443

application.tmpdir = /tmp/web-username

ssl {
    keystore.cert = cert.pem
    keystore.key = key.pem
}

Replace the word "username" with your username (leaving the web prefix). Jooby copies the certificate files into this 'tmpdir' folder so we need to make sure that you aren't all trying to share the same folder so that you don't have permission problems if you log in to a computer that an INFO202 student has already used for this lab.

Save and quit the text editor.

Run your application. You should now see two URLs being displayed in the output console when Jooby starts. Click the one that starts with https://.

The browser will likely show some scary warnings that state that you shouldn't trust this certificate. We created the certificate, so we know that we can trust it. The warnings are because there is no chain of trust associated with this certificate. The browser doesn't know that we created it --- it could have been created by a malicious attacker which would allow them to decrypt and eavesdrop on the network traffic.

Normally we would use a service like LetsEncrypt to create a certificate that has a complete chain of trust that the browsers are happy to accept, but we can't do that since LetsEncrypt needs to be able to confirm that you are the owner of the domain that is being registered, and you aren't --- the University is.

You can click the <

Note that there is nothing wrong with using self-signed certificates (which is what it is called when you create it yourself) if you control both the server and client. They are entirely secure. If your client is a desktop or mobile application that you are able to easily update then it is fine to use them. You just need to validate the certificate to make sure that it hasn't been altered before you use it.

The problem is when your client is an AJAX application and the browser starts showing scary warnings to your users. Telling your users to just click the "proceed to site" button is dangerous since we do not want to be training our users into bad habits. If they do get into the habit of just accepting dangerous certificates then they will never notice if the certificate does get swapped out by a malicious user.