Something just doesn’t feel “right” about running a development environment on a non-standard port over just HTTP. Not only is it bothersome to see the “Not Secure” message, it’s not a best practice. Your development environment should be as close to your production environment as possible.

While the main difference is that HTTPS will encrypt data in transit and HTTP will not, there’s another subtle one that’s also important. HTTPS pages will not allow Javascript to be called from HTTP-only URLs. Thus, if you don’t use HTTPS, this issue would not rear its ugly head until you deployed to production.

Creating & Installing the Certificate

It only takes a few minutes to get up and running with your own, trusted, self-signed certificate. The initial first few steps work for both Mac & Windows. Pay attention at the end, as adding the self-signed certificate as trusted varies across platforms. I’ve added a section for each OS.

Creating the Certificate

Let’s start by creating our self-signed certificate.

1. Open a new terminal window

2. Navigate to the ords_config directory. This was set up as part of my previous post here.

3. Create a new directory called ssl.

4. Navigate to the ssl directory.

5. Run the following command:

    openssl req -x509 -out cert.crt -keyout key.key -days 9999 \
      -newkey rsa:2048 -nodes -sha256 \
      -subj '/CN=localhost' -extensions EXT -config <( \
       printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
   

Some notes about this command:

• The bulk of this command was taken from this page: https://letsencrypt.org/docs/certificates-for-localhost/

• I set days = 9999 because I don’t want to be bothered to re-create this certificate. Ever.

• The name of the certificate pair - cert.crt & key.key - are what the ORDS container will look for, so don’t change them.

6. Upon running this command, you should have two files in the ssl directory:

   

Installing the Certificate

A simple restart of the ORDS container is all we need to switch over from HTTP to HTTPS.

Remember what I said about that non-standard port? Let’s change that to 443, so that we don’t need to put a port number in the URL at all.

1. Terminate your existing ORDS container.

2. Using this new command, restart the ORDS container:

    podman run --rm --name ords -v `pwd`/ords_secrets/:/opt/oracle/variables -v `pwd`/ords_config/:/etc/ords/config/ -v `pwd`/images/:/opt/oracle/apex/24.1.0/images -p 443:8181 container-registry.oracle.com/database/ords-developer:latest &
   

This command has one additional argument in it: -p 443:8181 That additional attribute will redirect port 8181 from the container to your local port 443.

As keen readers may have noticed, I’ve saved this command to a local file called start_ords. This way, I can just run that file to restart my container vs. sorting through my blog to find the command syntax.

Testing the Certificate

Let’s see what happens now what we try to access our ORDS container.

1. Open up a new browser window and enter the following URL: https://localhost

As expected, you should see the “Your connection is not private” error. This is because the certificate is self-signed, and the browser cannot associate it with one of it’s CAs.

You can click “Advanced” and then Proceed to localhost (unsafe), but that gets annoying pretty quickly.

Trusting the Certificate

While theres a number of ways to fix this issue, the quickest one that I have come by is to tell your local machine to simply “trust” this self-signed certificate as if it were signed by a legitimate CA. This takes just seconds, and agains, since this is a local development environment, is a perfectly secure approach to take.

Trusting the certificate will vary, depending on your local OS.

MacOS

To trust a self-signed certificate on Mac OS, we simply need to add the certificate to the MacOS Keychain.

1. Launch the application called Keychain Access.

2. Enter your credentials.

You should now see a window similar to this:

3. Using the Finder, navigate to the folder where you placed the certificates that you created earlier. It should be in /ords_config/ssl.

4. Drag the file cert.crt to the “striped” part of the Keychain Access window (under the column headings). You should see the following popup window:

   

5. Select Add.

6. On the main Keychain Access window, search for localhost. You should see a single entry:

   

7. Double-click the localhost entry.

8. Expand the Trust region.

9. Set When using this certificate to Always Trust. All other options should automatically change to Always Trust as well.

   

10. Close the localhost window. You will need to re-enter your credentials for the changes to take effect.

At this point, your local OS will trust our self-signed localhost certificate as if it were valid. You will no longer see the “Not Secure” message, either. Again, fine for development, not really a great idea for production systems.

We can prove this by reloading our browser that was pointed to https://localhost.

The results should look like this:

Windows

On Windows, you need to take similar steps to allow the OS to trust the self-signed certificate.

I did some searching, and this post seems to have a decent set of steps to do this. I did not have the chance to try this out, so please leave a comment if it doesn’t work or you have a better set of steps to use on Windows.

Summary

Even though it’s a local development environment, it’s important to try to mirror what’s on production as much as possible - including the protocol used to access APEX. It doesn’t take much work to create and install your own certificates into the ORDS container, ensuring that all web applications are accessed via HTTPS.