First Let’s Encrypt Certificate

Domain Validation (DV) certificates allow a host to prove that it is the correct host for a particular domain name. A common use case of DV certs is if a Web browser tries to connect to the Web server for a particular domain name, then the DV cert provided by the Web server gives the user confidence that he has accessed the desired Web server, rather than an impostor server than has somehow hijacked the connection.

Traditionally, DV certs cost money and were rather bothersome to obtain. Let’s Encrypt is a recognized Certificate Authority, which makes getting DV certificates easy, by making the process free, and by providing software and APIs which automate the process. In my opinion, projects like Let’s Encrypt are a necessary consequence of the move from IPv4 -> IPv6. IPv6 increases the bit length of IP addresses, making them more difficult to remember, while at the same time making it easier for individuals and small organizations to run many routable services on their own networks. So, it is important that you can easily give a DNS name to a particular host and that, having done so, you can have confidence that you are connecting to the correct host when you are on another part of the Internet. You might conceivably want 20 or 30 DV certs just for your home network, not to mention the office!

There is Let’s Encrypt compatible software for libreCMC, a package called acme. I haven’t actually tried it yet, though: it requires mbedtls, and I had stripped mbedtls from my builds in favor of openssl (a choice I might have to revisit). But I wanted a DV cert on my libreCMC gateway router. So, I used the certbot program from my Debian desktop to create the cert and then put it on my router.

root@nightshade:~# certbot certonly --manual --preferred-challenges dns
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):<snip email address>

Please read the Terms of Service at You must
agree in order to register with the ACME server at
(A)gree/(C)ancel: A
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel)
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for

NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
(Y)es/(N)o: Y

Please deploy a DNS TXT record under the name with the following value:


Once this is deployed,
Press Enter to Continue

Then I logged into my domain registrar, and added a DNS TXT record as indicated. Then I pressed Enter.

Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/ Your cert
 will expire on 2018-07-06. To obtain a new or tweaked version of
 this certificate in the future, simply run certbot again. To
 non-interactively renew *all* of your certificates, run "certbot
 - If you lose your account credentials, you can recover through
 e-mails sent to <snip email address>.
 - Your account credentials have been saved in your Certbot
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Certbot so
 making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:
 Donating to EFF:

Quite simple. Now, the cert chain and the corresponding private key needed to be loaded onto my libreCMC gateway router. However, libreCMC uses the DER file format, rather than the PEM format. So I needed to copy the files from fullchain.pem and privkey.pem from the /etc/letsencrypt/live/ directory, and convert them:

christopher@nightshade:~/Scratch$ openssl rsa -in privkey.pem -outform DER -out uhttpd.key 
writing RSA key
christopher@nightshade:~/Scratch$ openssl x509 -in fullchain.pem -outform DER -out uhttpd.crt

Then, these files needed to be copied onto the router, and placed in the /etc directly, replacing the default uhttpd.key and uhttpd.crt files (I had to adjust permissions as well to match).

After rebooting the uhttpd server, I accessed the LuCi interface using my domain name, and this time I did not need a security exception!

Screenshot from 2018-04-06 18-04-18

Screenshot from 2018-04-06 18-04-34

Screenshot from 2018-04-06 18-04-53

The Let’s Encrypt certs are only valid for three months, so I’ll have to do that again later. But it was pretty easy. If I can get ACME running on my libreCMC router, in theory I should be able to completely automate the process.

Gateway Router Upgraded

I upgraded my home gateway from a TPE-R1100 to a GL-AR300M. This turned out to be fairly easy as the settings backup file was portable to the new hardware. That makes sense as it is basically just /etc config files in a tarball, and the two devices have equal interface counts.

One oddity is that, instead of replacing the old wireless interface settings with the new ones, it created two wireless interfaces, one being disabled. But that was a quick fix.

Another oddity, which I’ve experienced before when swapping out hardware running libreCMC, has to do with the DHCP. I got my ISP to swap my static IPv4 address (served by DHCP) to the MAC address of the new device. However, libreCMC udhcpc mysteriously clung to the non-static address it had when I first plugged it in. Even after rebooting everything multiple times, and enabling and disabling the interface, and even sending various signals to udhcpc, I kept getting the old IP. It seems like libreCMC is either storing and requesting the old address, or it is somehow requesting the DHCP server not to allow it to change addresses. I took a glance at the DHCP protocol extensions but it was a bit overwhelming. About 24 hours later, I toggled the interface again, and the proper address finally came up. I’d be curious if anybody could suggest a possible explanation for that delay.

Anyway, now everything seems to be working great, and I couldn’t find any serious problems in the logs. That extra 112MB of flash and extra CPU power should expand the possibilities for what I can do at my gateway.

v1.4.3a Source and NAND build

v1.4.3a Source Release


LibreCMC v1.4.3a was recently released. Notable changes since v1.4.2:

  • CVE-2017-15107 patch
  • Bump to linux-libre 4.4.120
  • Bump versions on openvpn, mbedtls, openssl
  • Added LuCi shell-in-a-box support
  • Tor package added to base
  • nfs-server support added to core

Source package


Build for GL-AR300M with NAND flash:



Build features

  • Uses OpenSSL instead of MbedTLS
  • Default and Material LuCi themes
  • ca-certificates
  • nano, vim, zile
  • 6in4
  • ip neigh
  • netcat
  • tcpdump
  • nmap-ssl
  • nping
  • wget

Additional modules


  • openvpn
  • luci-app-openvpn
  • opentracker
  • opentracker6

Network Manager and IPv6 Privacy

This is somewhat off topic, since LibreCMC does not use Network Manager. However, Network Manager is common on Gnu/Linux desktops.

One question that can be asked about IPv6: If everybody uses public IP addresses, doesn’t that destroy privacy? One solution to this is the IPv6 Privacy Extensions. Basically, the Privacy Extensions allow your IPv6 host to generate random, temporary public IP addresses. So, a remote server will see your public IP address (in the packet’s source address) but it might not be the same one you were using an hour ago. That gives you at least the same level of privacy you had as a client hiding behind an IPv4 NAT.

That is a nice feature for browsing the Web. However, it is rather inconvenient for host-based firewall management. In my case, I have a remote firewall that only allows SSH access for one host, based on the packet’s source address. That means it will reject a random address that is used. One trick is to specify the source address in the ssh client command, to use the permanent public address:

ssh -b 2001:470:b:449::2d3 evenstar.<snip>.com

But that is rather inconvenient. I suppose a bash alias would reduce the inconvenience somewhat.

Alternatively, you can disable the Privacy Extensions, or at least de-prefer temporary addresses. I think the traditional way to do this was editing /etc/sysctl.conf, but it seems that those settings are overridden by Network Manager. In that case, you must use the nmcli program to edit your Network Manager profile settings. E.g.:

christopher@nightshade:~$ nmcli con edit Standard\ Wired

===| nmcli interactive connection editor |===

Editing existing '802-3-ethernet' connection: 'Standard Wired'

Type 'help' or '?' for available commands.
Type 'describe [<setting>.<prop>]' for detailed property description.

You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, dcb, ipv4, ipv6, proxy
nmcli> set ipv6.ip6-privacy 0
nmcli> save
Connection 'Standard Wired' (572cca57-4cae-4109-99c3-2a3282181043) successfully updated.
nmcli> quit

From the Gnome desktop, you can find out the name of the profile you are using by clicking the Gnome network manager icon. If you use command set ipv6.ip6-privacy 0, that disables the temporary addresses. If you use command set ipv6.ip6-privacy 1, that causes the temporary addresses still to be created, but not preferred (i.e., not used).