Serving Fossil

Page content

This post is going to be a bit technical, as I will describe in some detail the final setup for hosting for

Most of the steps that I follow come from Digital Ocean’s article How To Secure Nginx with Let’s Encrypt on Ubuntu 16.04. The only step not necessary from these instructions was Step 3 on Updating the Firewall. The AWS Ubuntu images do not have an active firewall, as their networking configuration has a fairly aggressive firewall already in place.

IPv6 with EC2

IPv6 support is fairly new with Amazon EC2, but having it now eliminates one of my the main reasons I have been avoiding using EC2 for my hosting. However, it still does not seem to be enabled by default, so there are some additional steps that need to be taken. I followed the steps in VPC Migrate IPv6. Once the IPv6 is enabled in the VPC configuration, it will mostly work with any added hosts, and these steps do not have to be repeated again.

I created an EC2 t2.nano instance based on Ubuntu 16.04 LTS. The main thing to select was to change the default so that the configuration would give my host an IPv6 address. After the host came up, I had to ssh to it using IPv4 and add a single line configuration file:

$ cat /etc/network/interfaces.d/60-default-with-ipv6.cfg
iface eth0 inet6 dhcp

which will bring up IPv6. After adding this, sudo reboot the target, and reconnect over IPv6. I initially created DNS A and AAAA records for this host until a utility name (fossil, since I was trying to bring up Fossil). This would give a little smaller of a window when my old website would be down.

I then did a few things to configure this machine:

$ echo export EDITOR=vim >> .bashrc
$ # add -CFS to ls alias in .bashrc
$ # Make the host aware of its own name.
$ sudoedit /etc/hostname
   set to
$ sudo reboot

Getting a certbot

At this point, I followed the steps at How To Secure Nginx&ldots;. In addition, I had to add a line:

	listen [::]:443 ssl;

to /etc/nginx/sites-available/default so that it would also listen for SSL on IPv6.

I requested a certificate with,, and It was necessary to change DNS, and allow it to propagate before making the certificate request, since it verifies control over the hosts named. All of these point to this new host.

After this is set up, I verified that the plain nginx page came up when I requested these sites, and that the server would force a redirect to the HTTPS site.

I also verified, using SSL Labs server test, that I received an A rating on all of the addresses, at both IPv6 and IPv4. I’ll discuss in a moment what is needed to get an A+ rating.

Static pages and Fossil

I made the static site directory /var/www/html writable by the ‘ubuntu’ user, and used rsync to push my static site there. At this point, the static site (where this blog is) is working on my domain.

My old website was maintained using Fossil. To keep this around, I migrated the fossil data to the new machine, and added a small configuration block to the server block in the Nginx configuration:

	location /fossil/ {
		rewrite ^/fossil/$ https://$server_name/fossil/home/index;
		include scgi_params;
		scgi_pass localhost:9000;
		scgi_param SCRIPT_NAME "/fossil";
		scgi_param HTTPS "on";

This hands all URLs that start with “fossil” to the scgi fossil application. I had to fix a few URLs within fossil to handle now having a “/fossil/” prefix in the URL, but otherwise this works.

Getting an A+ rating

Going through the SSL Labs report, there were a few things I could go through and fix. I was able to get rid of all of the red highlighted items, and only a few ciphers that it considers weak, that the Lets Encrypt forums disagree with.


The Certification Authority Authorization (CAA), specified in RFC 6844 requires a DNS record to give some additional guidance as to which certificate authorities are allowed to issue certificates for the domain. See this blog article for more information. I would like to be able to use both the certificates I get from letsencrypt, as well as those from Amazon (to use cloudfront).

I had a little trouble tracking down what to use for the CAA records. Letsencrypt is discussed fairly widely. I’ll try using the domain “” found in the certificate coming from CloudFront. CAA 128 issue "" CAA 128 issue ""

There is some suggestion from Mozilla that this will be accepted.

Weak ciphers

The report also shows a handful of SSL/TLS ciphers that it considers weak. It seems that the Certbox client is already configuring the list of ciphers, so fixing this would probably involve discussions between Letsencrypt and the SSL Labs report. The forum suggests that the problem is more with the report, and that I shouldn’t be striving for the A+ just because of this.


There are quite a few steps necessary to get this set up (which is why I’ve documented it here). But overall, this setup allows me to host both a static site, as well as an active web app (Fossil) on AWS, for under $5 a month.