Hayden Hudson
Let's Encrypt: Oracle Linux

Let's Encrypt is a service to provide SSL Encryption to your website that is both free & easy to use (provided you can meet these basic requirements). In the spirit of promoting it's adoption, I'm writing this post to address the experience of implementing Let's Encrypt service in an Oracle Linux 7 environment with Apache, a combination that is not specifically handled in their (otherwise very user-friendly) guided help.

Let's Encrypt is mobilized in a worthy cause:
"to create a more secure and privacy-respecting Web"
Let's Encrypt is mobilized in worthy cause:
Beyond the basics, a case can be made that Let's Encrypt is an answer to a social pain-point: Net Neutrality and internet privacy. The Let's Encrypt price-point of $0.00 should accelerate us towards universal website encryption. In such a world, concerns about ISPs spying on and selling our web traffic data should be much reduced.

There are many resources reviewing the pros and cons of Let's Encrypt (for e.g.). To add my 2 cents to the pile: the biggest drawback of the Let's Encrypt design, from my perspective, is that you cannot implement it on an intranet.

Meanwhile, I wholeheartedly embrace the Let's Encrypt requirement that certs be renewed every 90 days, because it improves the security of the encryption. I say we should renew the certificates with even greater frequency!

Key learning: Oracle Linux = 'Other Unix'

Implementing Let's Encrypt on Oracle Linux is super simple once you've figured out that you should follow the instructions for 'Other Unix'.

Following the instructions, I downloaded and enabled Certbot:
# wget https://dl.eff.org/certbot-auto
# chmod a+x certbot-auto
I completed the process by running through the Certbot wizard:
# ./certbot-auto certonly
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Failed to find executable apache2ctl in PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

How would you like to authenticate with the ACME CA?
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): 2122.io
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 2122.io

Select the webroot for 2122.io:
1: Enter a new webroot
Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
Input the webroot for 2122.io: (Enter 'c' to cancel): /var/lib/tomcat/webapps/2122
Waiting for verification...
Cleaning up challenges

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2017-11-27. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
Initial mistake : Oracle Linux != 'CentOS/RHEL 7'

It may be of interest to record that I attempted to follow the instructions for CentOS/RHEL 7 without success.

Attempted to get yum install to work by enabling EPEL repository
# wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-10.noarch.rpm
# rpm -ivh epel-release-7-10.noarch.rpm

After enabling the EPEL repository, I was then stymied in my attempt to 'yum install certbot-apache' by a dependency on 'python-zope-interface'. I considered installing 'python-zope-interface' but got cold feet as I got concerned for the maintainability of what I was doing.

Server Configuration details
Created some soft links:
# ln -s cert.pem 2122.crt
# ln -s privkey.pem 2122.key
# ln -s chain.pem 2122_chain.crt

I created these soft links (in the path /etc/letsencrypt/live/2122.io) because Apache didn't appear to like '.pem' files being supplied in the standard ssl.conf virtual host fields (see below).

Added a virtual host to ssl.conf:
<VirtualHost *:443>
  DocumentRoot "/usr/share/tomcat/webapps/2122"
  ServerName 2122.io
  ServerAlias www.2122.io
  SSLEngine on
  SSLCertificateFile      /etc/letsencrypt/live/2122.io/2122.crt
  SSLCertificateKeyFile   /etc/letsencrypt/live/2122.io/2122.key
  SSLCertificateChainFile /etc/letsencrypt/live/2122.io/2122_chain.crt

Of note: there was a challenge to including several virtual hosts in the same ssl.conf file. Employing the above syntax for all my virtual host entries agreed with Apache.

Edited my httpd.conf:
<Directory "/usr/share/tomcat/webapps/2122">
    Options MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
    # Allow open access:
    Require all granted

Adding a directory to your httpd.conf is only a requirement if you wish to TLS encrypt files (such as images) in the path of your Document Root (which in my case is "/usr/share/tomcat/webapps/2122").

Created a cron-job to auto-renew:
# crontab -e
0 0 1 * * /usr/local/src/certbot/certbot-auto renew

This step shouldn't be a surprise if you noticed the part about Let's Encrypt certs expiring every 90 days. You are welcome to schedule your cron-job to attempt to renew the certs every minute, there's no harm in it. The attempt to renew will be ignored until you are within 30 days of expiration (for now).

No need to add certs to Oracle DB 12c release 2
I can run make_rest_request without additional steps:
l_ws_response clob;
l_ws_url varchar2(1000);
     l_ws_url :='https://2122.io/apex/demo_api';
    l_ws_response := apex_web_service.make_rest_request(
    p_url               => l_ws_url,
    p_http_method       => 'GET'
There was no need to add the certificates to the Oracle Database 12c release 2, which is convenient.
Date : Sept. 27, 2017