My Little Corner of the Net

Setting Up a Raspberry Pi From Scratch

The SD card on one of my Raspberry Pi systems filled up recently, so I decided to wipe it and reinstall Raspbian. The main Rasbian distribution, however, is designed to help teach kids to code and includes lots of tools that I generally don’t use, so I decided to build it from scratch.

The Raspberry Pi Foundation provides a light version of the Raspbian OS, which is intended for Pis used as servers or in embedded devices. Raspbian Jessie Lite doesn’t include a graphical interface by default, nor does it include any of the various browsers, office tools, or programming tools that you’d normally expect to see on a Pi. It’s pretty much just the basic OS and the standard utilities you’ll to find on any Linux machine.

To get started, download the latest Raspbian Jessie Lite image and use your method of choice to install it on your SD card. Since I’m working form a Mac, I usually use IvanX’s Pi Filler. Once the card is built, stick it in your Pi, boot up, and run raspi-config right away to set up your Pi and change your password.

sudo raspi-config

Since this is an advanced tutorial, I’ll assume you’re already familiar with raspi-config, so I won’t spend time on it here. If you need help, there are plenty of tutorials online.

Now, I’ve never been a fan of the Raspberry Pi’s desktop environment, LXDE. I just don’t really like how it looks and it’s difficult to customize. PIXEL, the new implementation of LXDE on new versions of Raspbian is a little better looking, but I still can’t get into it. Instead, I much prefer XFCE, another lightweight desktop environment. Unlike LXDE, you can configure XFCE up the ying-yang, making things look exactly the way you want.

We first need to install the XWindow system, which is the low-level software that allows graphical desktops. Since we don’t want to accidentally install any of the default PIXEL libraries, however, we’ll use the -—no-install-recommends option with apt-get:

sudo apt-get install -—no-install-recommends xserver-xorg
sudo apt-get install -—no-install-recommends xinit

Next we’ll install XFCE, the XFCE terminal application, and the LightDM display manager:

sudo apt-get install xfce4 xfce4-terminal lightdm

This will install a ton of dependencies, and will take a while to complete.

At this point you could run startx and have a working system, but it would be extremely basic, so we’ll also add a bunch of XFCE utilities. These let you add desktop features like status bar icons and desktop widgets that help make the interface more user friendly:

sudo apt-get install xfce4-goodies xfce4-indicator-plugin xfce4-limelight-plugin xfce4-mpc-plugin xfce4-whiskermenu-plugin

Now lets start the graphical environment:


The first time you run XFCE, you’ll see a screen that looks something like this:

XFCE First Launch

The first time start XFCE, you’ll be prompted to set up your desktop.

XFCE can be configured in a lot of different ways, and everyone has their own preference. Personally, I prefer something that looks kind of like an older Windows system with a bar at the bottom of the screen featuring an application menu, buttons to indicate running programs, and some status indicators, quick access menus, and the like. I’ll take you through my personal preferred setup in the next few steps, but feel free to customize things to your liking.

First, click the “One empty panel” button in the dialog box. A small white box will appear near the top of the screen.

First Panel

The first panel will initially appear near the top of the screen.

Drag the box to the bottom left corner of the screen. Right click on this box and choose “Panel preferences…”

Panel Preferences

Right click on the panel and select Panel Preferences.

On the “Display” tab of the Panel dialog, set the mode to “Horizontal,” the row size to 32 pixels, number of rows to one, and the length to 100%.

Panel Preferences

Sample settings for the panel.

Next, click on the “Items” tab. The click the “+” button to start adding items to the panel. Below is the list of items I use on my panel, in order from left to right:

* Whisker Menu (an application launcher similar to the “Start” menu in Windows)
* Separator
* Window Buttons
* Separator
* Workspace Switcher (lets you quickly change between virtual desktops)
* Notification Area (a place for applications to show status indicators; for example, a email app might indicate when you have new messages)
* Show Desktop (minimize all windows)
* Audio Mixer (control the speaker volume)
* Wastebasket Applet (quick access to your system’s trash)
* Clock
* Action Buttons (this give you quick access to functions like lock screen, logout, and reboot)

Feel free to add other options that make sense for your system. For example, if you’re using WiFi, you might want to add the Wavelan item to help you manage your wireless network connections. When you’re done, your screen should look something like this:

Customized panel

The newly customized panel.

Most of the panel items have a set of preferences that go along with them which you can access by selecting the item you want to configure and clicking the properties button. It probably looks like a wrench on top of a sheet of paper and is located just below the “-“ button.

You can explore the settings on your own, but to help make things look a little cleaner, choose the second separator and click the properties button. Then check the “Expand” checkbox and click “Close.” That pushes the items after the separator up against the right side of the screen and makes the panel look more balanced.

Separator Preferences

Expanding the separator helps balance the look of the screen.

Now close the Panel dialog. We’ve got our desktop set up, but it still looks a little blah. Let’s do something about that.

Use the newly added Whisker Menu to run the Terminal Emulator, which should be at the top of the list.

Using Whisker Menu

running the terminal emulator from the Whisker Menu.

We’ll now add some additional desktop themes (which set the style and color of system elements like window borders, buttons, and the like), icons, and background images. We’ll start with the themes. At the moment, I’m really liking the MurrinaBlue theme that’s part of the Murrine theme package:

sudo apt-get install gtk2-engines-murrine

And, although I’m not a big fan of PIXEL, I really do like its background images:

sudo apt-get install pixel-wallpaper

Finally, we’ll install the Elementary icon set. ElementaryOS is a lesser-known Linux distribution, but it has one of the nicest, most professional looking sets of icons I’ve seen—and they work well with XFCE.

While some Linux distributions have an XFCE-Elementary icon package available, Raspbian does not, so we’ll simply clone it from GitHub.

First install git:

sudo apt-get install git

Then run these commands:

sudo mkdir /usr/local/share/icons
cd /usr/local/share/icons
sudo git clone elementary

Now open the Whisker Menu, type “appearance,” and open the “Appearance (Customize the look of your desktop)” applet that appears.

On the Appearance dialog’s “Style” tab, you’ll see a long list of desktop themes. As you select them, your screen will change to show you a preview. As I noted earlier, my go-to theme is currently MurrinaBlue.

Selecting a Desktop Theme

Selecting a theme for the desktop

Next, click on the Icons tab. Again, as you click through the various options, you’ll see the desktop change. Choose “elementary” (not “elementary Xubuntu dark”).

Selecting an Icon Set

Selecting an Icon Set

Now close the Appearance dialog, right-click on the desktop, and select “Desktop Settings.”

Desktop Settings

Right click on the desktop and select Desktop Settings,

You’ll see that XFCE already comes with several wallpaper images, but we want to use the PIXEL images, so click the “+” button:

Selecting Desktop Images

Click the “+” icon to add additional wallpaper imeages.

In the “Add Image File(s)” dialog, click in the whitespace of the file listing (middle box) and start typing /usr/share/pixel-wallpaper and then press enter.

Click on the first image (aurora.jpg), then scroll to the bottom of the list, hold down Shift, and click on the last image (waterfall.jpg) to select the entire set of images. Then click add. Now select your wallpaper and close the Desktop dialog.

Selecting PIXEL Wallpaper

Selecting all of the PIXEL wallpaper images will make them available in the XFCE Desktop Properties window.

Now that we’ve gotten everything set up, you’ll probably want to open a terminal window and run raspi-config again.

sudo raspi-config

Go to “Boot Options,” and “Desktop / CLI,” and chose to boot to “Desktop” instead of the default, command-line interface. Reboot when prompted.

Now you’ve got a basic system, but it doesn’t do much. You need some software. You’ll probably want a web browser or two:

sudo apt-get install firefox-esr chromium-browser

Maybe an office suite (I’m also including the LibreOffice SIFR icon set, as it’s much nicer looking than the default set):

sudo apt-get install libreoffice libreoffice-style-sifr

You’ll probably want a PDF viewer:

sudo apt-get install xpdf

And don’t forget an email client:

sudo apt-get install icedove

That should be enough to get you started. There is, of course, a ton of other software you can install, depending on your needs. Poke around on the Internet and you’ll be sure to find applications to do just about anything you want.

Extra Credit

When you rebooted after switching to the “Desktop” login, you probably noticed that the default Debian wallpaper appeared under the login dialog. Want to change that?

One a terminal window and type:

sudo vi /etc/lightdm/lightdm-gtk-greeter.conf

If you don’t like vi, feel free to use your preferred editor (such as nano), but if you’re going to be a Linux user understanding vi is a very useful skill that you should really take the time to learn. And don’t worry, I’ll clearly explain everything.

Press the / key (forward slash) to search the file and then type background (without the quotes, of course), followed by the n key (for “next match,” since the word background appears once before in the file), which will jump you to where the login screen’s wallpaper image is set.

Use the arrow keys to position the cursor on the first / after the equals sign and press the c key (for “change”), followed by the $ key (shift is required), which tells vi that you want to edit everything to the end of the line.

Now type the path to one of the PIXEL wallpaper images, such as


So that the entire line looks like this:


When you’re done typing, press the esc key and then type :wq (colon, w, q, which tells vi to write the file back to disk and then quit.

Now reboot the Pi again and you should see a much more welcoming login screen.

Extra Credit Part II

Now that you’re on your quest for software to install on your Pi, it might make sense for you to install a graphical package manager. Let’s face it, using apt-get to install packages or run updates is pretty easy, but using the command line to search for packages? Not so much.

The graphical package manager I generally prefer is called Synaptic. It’s pretty no-frills as far as the interface goes, but it’s easy to use and gets the job done. Like everything else, you can install Synaptic via apt-get:

sudo apt-get install synaptic

Synaptic will automatically add itself to the Whisker Menu (under “System,” but the default settings use an internal mechanism for prompting for the root user’s password to get the necessary privileges to install packages. By default, most Debian-based OSes, such as Raspberry don’t set a root password, so the menu item won’t work.

Fortunately, it’s easy to fix. First, you’ll need to install gksu, a package containing graphical equivalents to the su and sudo command-line programs:

sudo apt-get install gksu

Next we need to edit the synaptic.desktop file that creates the menu item. We can do this is one quick step:

sudo sed "s/synaptic-pkexec/gksudo synaptic/" /usr/local/share/applications/synaptic.desktop

This creates a new synaptic.desktop file in /usr/local/share/applications with an updated command in it. Without getting into the differences between /usr and /usr/local, the file in /usr/local will take precedence over the one in /usr, and we don’t have to worry about it getting overwritten when an updated package is released.

Now, when you select Synaptic from the Whisker Menu, you should get right in to the app without being prompted for an non-existing password.

Extra Credit Part III

Sometimes you may want to add your own items to your Whisker Menu. While it’s not too difficult to manually write the .desktop files yourself, there’s a much easier way: using a menu editor. One such menu editor that’s available for the Pi is called MenuLibre.

To install MenuLibre, run:

sudo apt-get install menulibre

MenuLibre will add itself as “Menu Editor” to the Accessories and Settings menus in Whisker Menu. Run it and you’ll have access to tweak any of your system’s menu items, or even add new ones.

The .desktop files that MenuLibre creates are stored in your own account and will only appear in your menu, not the menus of other users of the system (assuming you have any). If you want to share them, you should move the files from ~/.local/share/applications to /usr/local/share/applications:

sudo mv ~/.local/share/applications/myapp.desktop /usr/local/share/applicatons

Printing Pi

A while back I somewhat impulsively bought a floor-model Brother MFC-7365DN printer that was on the clearance shelf at Sam’s. I say somewhat impulsively because I needed a new printer and I was seriously looking at the Brother MFC line, but I didn’t know much about this particular model and hadn’t, prior to walking in to the store at least, completely decided on that line of printers. The deal was too good to pass up, though, and the printer has proven itself to be a great decision.

One thing that I didn’t know (and didn’t really think much about) going in to the purchase was Linux support. As it turns out, Brother has great support for Linux, but only for x86 devices. Their Linux drivers are proprietary and they don’t offer source code, so printing from ARM devices is a challenge. There’s plenty of discussion online about which Gutenprint drivers usually work (none of the recommendations I found did more than push out blank sheets of paper, if anything at all) or using QEMU to emulate x86 hardware (which was reported as being extremely slow, so I didn’t try).

I generally don’t print from my Raspberry Pis directly but, as we use Google Apps more and more at work, I find myself wanting to use Cloud Print more often. I really wanted, as I had done in the past, to set one of my Pis up as a Cloud Print server, but without a printer driver that wasn’t happening. In fact, I even went so far as to create an extremely kludgy, but surprisingly effective, solution that involved an always available SSH connection (using autossh and a dynamic DNS service) between a remote x86-based VPS and one of my Pis, with a tunnel to my printer. I then set up Cloud Print on the server and used that as my workaround…until this weekend.

I was browsing some packages in Synaptic when I decided to search for “Brother.” I’m pretty sure I did this before with no luck, but this time I found a package, printer-driver-brlaser, described as a “CUPS filter driver supporting (some) Brother laser printers,” which appears to be distributed by the OpenPrinting project. One of the printers listed was model DCP-7065DN–a model number quite similar looking to my printer’s. On checking out the specs for the DCP-7065DN, it looked to be pretty much the same printer as mine, less the fax capabilities, so I installed the package, set up the printer in CUPS (which was already installed from previous attempts), selecting “Brother” as the make and “Brother DCP-7065DN” as the model, and printed a test page…successfully!

I should note that CUPS found my printer automatically, but I couldn’t get it to work from the discovered selection. Instead, I manually configured the printer’s address to be socket://IP_ADDRESS:9100 (with my printer’s IP address in place of IP_ADDRESS, obviously). The driver didn’t give me an option to set the duplex default, so I’m not sure if I’ll be able to do two-sided printing or not (I haven’t tried printing anything longer than one page yet), but it’s not the end of the world if I can’t.

Just thought I’d share my experience as there seem to be lots of frustrated Brother owners trying to print from ARM devices out there.

Single Site Browser on the Raspberry Pi

Sometimes it’s easier to work with a standalone app than it is to use a web app in a browser—if you want to keep an eye open for to a chat or you need to copy and paste from other windows, it’s much easier to do if the app isn’t buried in a million tabs. Unfortunately on Linux, and especially on non-x86-based Linux, there are often no native apps available for the services I want to use.

I’ve been a fan of single site browsers—tools that let you wrap a web application into a stand alone desktop application—for quite some time. I originally discovered (and blogged about) Mozilla Prism back in the early 2000’s (though back then, I didn’t really see the point). Later, when I switched over to Macs and OSX, I found Fluid, which has been helpful for a handful of tools I use.

Nowadays, with Raspberry Pis being a hobby, I was looking for something similar. Even though a lot of the apps I use everyday are starting to support Linux, many do not distribute versions that are compatible with the PI’s ARM processor. Having a SSB for the Pi would be great…and, as it turns out, it can be done!

Peppermint is a Debian-based OS that features an SSB tool, called Ice, as one of it’s main selling features. Unfortunately, Peppermint won’t run on the Pi, but I figured with a little work, I might be able to get Ice to run. Ice, it turns out, is just a Python app, so it wasn’t difficult at all…I just needed to figure out a bunch of dependencies.

Ice requires Python 3, which I believe was installed by default on Raspbian Jessie (it’s been a while since I’ve rebuilt, but I don’t remember installing it manually). You will, however, need to install Glade and PyOpenGL and, if you don’t already have it, the git client:

sudo apt-get install glade python3-gl git

You’ll also need either the Google Chrome, Chromium, or Firefox browser, none of which are available on the Pi. Ice is, however, able to find Iceweasel, the rebranded version of Firefox that is available on the Pi, so you’ll want to have that installed, too:

sudo apt-get install iceweasel

While Iceweasel works, Chromium seems to be a little more flexible, so you might want to consider adding it as well. I’ve found kusti8‘s unofficial Chromium repo to be helpful in this regard.

You’ll also need to be sure you have the Python request package, which you can install with pip:

sudo pip3 install request

Now you’re ready to clone Ice from GitHub and copy it into place in the file system:

git clone
cd ice
cp -r . /

Once this is done, you should see an Ice icon in the Internet section of the RPi Main Menu:

Ice icon in the programs menu

Ice icon in the Raspberry Pi programs menu.

Running Ice brings up it’s configuration Window. Here I’m creating an app to access my work Slack:

Configuring Ice to run Slack as an application.

Configuring Ice to run Slack as an application.

When you click “Apply,” a new icon is added to the menu group you selected in the “Where in the menu?” field:

Slack in the programs menu

An icon for Slack has been added to the programs menu.

Running my new Slack app brings me to the Slack login page. Just a quick login and I’ll be collaborating with my team!

Slack login page in the Ice App

The newly created Ice app showing the Slack login page.

Let’s Encrypt on VestaCP with CentOS 6

As promised a couple weeks ago, I’ve created a tutorial for automatically installing Let’s Encrypt certificates on Vesta-hosted sites. As you’ll recall, Let’s Encrypt is a new certificate authority that issues free domain validated (DV) certificates to virtually anyone in an effort to make the web more secure. Let’s Encrypt tries to be fully automated, meaning that you just run a single command on your server and it takes care of all the details of certificate issuance for you: creating the private key and CSR, validating domain ownership, generating the cert, and even configuring the web server for you. Unfortunately, Let’s Encrypt and Vesta use different naming conventions for the certificate files, so the two don’t automatically play nice together. Thanks to Vesta’s command-line tools, however, it is pretty easy to bridge the gap.

TL;DR version: I’ve created a tool, which I’ve posted to GitHub, that automates the Let’s Encrypt certificate request and installation process using the Let’s Encrypt ACME client and Vesta’s command-line tools. You can clone my repository and get to work installing certs on your server.

You should be logged in a root to complete this tutorial.

Installing Python

The Let’s Encrypt client requires Python 2.7, which is not installed on CentOS 6.x by default. Simply upgrading Python will break several system utilities, like yum, so we’ll start by installing Python 2.7 in an alternate location. If you’re using a distro that includes Python 2.7, or you already have it installed, you can skip the next several steps.

First, using yum, install the development tools and libraries we’ll need to build Python from source.

yum groupinstall "Development tools"
yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel

Download the latest version of the Python 2.7 branch (2.7.11 as of this writing, but check and update the version numbers as appropriate.


Unzip the Python tarball and change into the newly create source directory.

tar xf Python-2.7.11.tar.xz
cd Python-2.7.11

Run the configure script.

./configure --prefix=/usr/local --enable-shared LDFLAGS="-Wl,-rpath /usr/local/lib"

Build and install the new Python binary. We’re using “make altinstall” to ensure that we don’t interfere the system version of Python (this will name the binary python2.7 instead of just python).

make altinstall

Thanks to Daniel Eriksson and Too Much Data for the How to install Python 2.7 and Python 3.3 on CentOS 6 post, from which my instructions are based. I highly recommend reading that post, as my instructions are only the bare minimum needed to get Let’s Encrypt working.

Installing Let’s Encrypt

Now that we have the right Python version, we can install the Let’s Encrypt ACME client. We’ll also install my installation tool (which isn’t much more than a bash script).

/usr/local is intended for locally installed software (as opposed to system provided software), so it seems like a good place to put these tools.

cd /usr/local

Clone the official Let’s Encrypt ACME client and my installation tool from GitHub.

git clone
git clone

Let’s Encrypt’s ACME protocol validates that a requestor is in control of the domain by checking for a the availability of a randomly named file over the web. It can do this with its own web server, or it can write a file to the web root of an existing server running on the domain. Since a Vesta server has many different web roots, we’ll tell let’s Encrypt to write these files to a central location and then configure Apache to look there for incoming validation requests.

First, create the Let’s Encrypt webroot directory.

mkdir -p /etc/letsencrypt/webroot

Then create a symlink to the letsencrypt.conf file in my GitHub repository.

ln -s /usr/local/letsencrypt-vesta/letsencrypt.conf /etc/httpd/conf.d/letsencrypt.conf

Finally, restart Apache so it will pick up the configuration change.

service httpd restart

Everything is installed and ready to go, but to run the tools you’ll need to specify the full path to them, since they aren’t in your PATH environment variable. A quick fix for this is to symlink them inside /usr/local/bin.

ln -s /usr/local/letsencrypt/letsencrypt-auto /usr/local/bin/letsencrypt-auto
ln -s /usr/local/letsencrypt-vesta/letsencrypt-vesta /usr/local/bin/letsencrypt-vesta

Now you’re ready to create your first certificate.

lets encrypt-vesta USERNAME DOMAIN

Substitute a valid Vesta user account for USERNAME and a domain hosted on that account for DOMAIN. The script will look up the account and pull the email address listed with it, using that as the contact email used in the certificate request. It will also look up the list of domain aliases associated with the domain and will include all of them as subject alternate names (SANs) in the certificate request. SANs function as additional domains on the certificate—each one will be recognized as a trusted domain by users’ browsers.

The first time you run the script, the Let’s Encrypt client will do some setup work, so it may take a minute or two. Future runs won’t require this additional work and should complete faster.

The certificates issued by Let’s Encrypt are valid for 90 days. It is recommended that you renew them every 60 days to allow ample time to mitigate issues such as reissue errors and service interruptions that might occur and leave you with an expired cert.

Let’s Encrypt is currently in beta and, while they offer unlimited certificates, they do have some limitations in place, at least for now. As of this writing, they currently only allow ten certificate requests from a single IP address over a three hour period and limit the number of SANs on a single certificate to 100. There are also limits on the number of unverified requests (as in a certificate is requested, but the validation process fails) allowed, though this shouldn’t be ann issue for most admins. These numbers may change over time as the technology platform matures and demand for the service adjusts.

Let’s Encrypt Enters Public Beta

There’s a new certificate authority in town, and it seeks to change the way we think about web security.  Let’s Encrypt, run by the Internet Security Research Group (ISRG), a partnership of a number of Internet-focused organizations like the EFF, Mozilla, Cisco, Akamai, and now Facebook, entered it’s public beta period this week and is now issuing free, browser-trusted, domain-validated certificates to pretty much anyone who wants them.

I’ve been doing some experimenting with Let’s Encrypt for the past few weeks as part of their limited beta program, and this post was already in the works.  In fact, I hadn’t even noticed that they entered public beta until after I started writing it and I went to the site to check on some facts.

While there are many issues with the SSL/TLS current certificate issuing paradigm, Let’s Encrypt aims to solve one of the biggest: the barrier of entry.  Not only are Let’s Encrypt certificates free, the process for getting them is mostly automatic.  To contrast, I’ve used another CA to obtain free certs for a number of my personal sites and projects for years and the process to get them is not easy.  With that CA, getting a new certificate is a multi-step process which includes  creating a client certificate to authenticate with the service, installing it in my browser, multiple steps of verifying domains, email addresses, and the like, waiting for verification codes to come by email, and manually installing the certificates when they arrive.  That CA also doesn’t support Subject Alternative Names (SANs), so I’m limited to creating certificates that work with only one domain or subdomain.

With Let’s Encrypt, after a little bit of one-time server setup, I just run a single shell command and it does everything for me (or most of it, anyway).

Before going too much further, let’s point out that Let’s Encrypt is not for everyone.  The certificates they issue are domain validated (DV), which means that the only validation done is a check that the server responding to the domain name in the certificate request is actually aware of the request.  As such, there is no information about the organization running the site in the certificate, so while a Let’s Encrypt certificate will enable encrypted connections in browsers (and without any certificate warnings), it does nothing to validate that the server is actually being run by the entity that it purports to be.  Because of this, Let’s Encrypt certificates probably shouldn’t be used for most production-level sites, especially not for ecommerce, banking, or anything else where a high level of trust is required.  On the other hand, they could be perfect for dev and test servers, where the level of trust is not required.

Let’s Encrypt intends their certificates to be used on the millions of personal sites, running software like WordPress, where site owners log in in the clear.  These kinds of sites are often the targets of hackers because (among many other reasons) people tend to reuse passwords, so the clear-text passwords they use to log in to their blog may very well be the same ones they use to log in to their banks.

So how does automatic certificate generation work?  In a nutshell, you install the Let’s Encrypt software on your server and use it to request a certificate for one or more domains.  The client uses the Automated Certificate Management Environment (ACME) protocol, which was developed by Let’s Encrypt, to submit the certificate request (which it generates for you), to the Let’s Encrypt CA.  The CA then verifies the request by checking that a specific file, created by the client software, is available from your server via the web.  If the server finds the file, the domain is verified, and the certificate is issued.  If the request is made for a domain that isn’t hosted by the server, the verification will fail, and the certificate won’t be issued.  When the certificate is issued, it’s returned to the client which will save it to the server and, depending on the implementation, may also reconfigure the web server to use the certificate for the domains it covers.

Let’s Encrypt supports SANs on it’s certificates, so it’s possible, for instance, to cover the .com, .net, and .org variants of a given domain, with both and without www prefixes, in a single cert (this isn’t even possible with the most commercial CAs, unless you are willing to pay for it—SANs are usually a premium feature and it usually costs almost as much to add an additional domain as it does to get a whole new cert).  Let’s Encrypt also says that wildcard certs are in the works, though there are some issues they need to work through concerning how to validate them, since a wildcard certificate would be valid for any subdomain on the domain it was issued to.  Fortunately, since there’s no limit to the number of SANs you can add or the number of certificates you can request (within reasonable limits, for now, at least), wildcard certificates would only be necessary in some very specific use cases.

The biggest downside to Let’s Encrypt is also one of it’s biggest strengths: certificates are only valid for 90 days.  This is a stark contrast to the current industry standard that allows certificates to be issued for up to two years and terms of five years or more being common not that long ago.  The 90-day limit means that site owners need to stay vigilant of expiration dates, but in a world of script-kiddie exploits and expired domains getting scooped up by domain squatters faster than you can say “connect,” it’s a pretty smart idea to recycle certificates quickly.  Plus, renewing is as easy as running the ACME client again, and an auto-renewal process is promised somewhere down the road.  For now, most monitoring tools can warn about certificate expiration in advance of it happening.  Let’s Encrypt recommends renewing every 60 days to ensure there’s plenty of time to fix any issues that may come in in the renewal process.

If a public key ever gets compromised, revoking a certificate is easy, too…it’s just another command to the Let’s Encrypt client.  Remember that other CA I mentioned?  They actually charge a fee to revoke a cert and won’t issue a new one until either the old one expires or you revoke it, even if you just lost the private key because of stupidly copying another file on top of it…not that I’ve ever done that!

I figure I’ll probably start replacing my free certs with Let’s Encrypt certs as they expire.  Using them will be a bit more work in that I’ll have to remember to renew them every couple months, but I’m working on a script that handles the installation process with Vesta, where most of my sites reside, so the process will be much, much easier than it is now.  I plan to release this script once I’ve done some thorough testing, so watch for another post in the next week or so.