User Guide¶

letsencrypt-auto¶

letsencrypt-auto is a wrapper which installs some dependencies from your OS standard package repositories (e.g. using apt-get or yum), and for other dependencies it sets up a virtualized Python environment with packages downloaded from PyPI [1]. It also provides automated updates.

To install and run the client, just type...

./letsencrypt-auto

Throughout the documentation, whenever you see references to letsencrypt script/binary, you can substitute in letsencrypt-auto. For example, to get basic help you would type:

./letsencrypt-auto --help

or for full help, type:

./letsencrypt-auto --help all

letsencrypt-auto is the recommended method of running the Let’s Encrypt client beta releases on systems that don’t have a packaged version. Debian, Arch Linux, Gentoo, FreeBSD, and OpenBSD now have native packages, so on those systems you can just install letsencrypt (and perhaps letsencrypt-apache). If you’d like to run the latest copy from Git, or run your own locally modified copy of the client, follow the instructions in the Developer Guide. Some other methods of installation are discussed below.

Apache¶

If you’re running Apache 2.4 on a Debian-based OS with version 1.0+ of the libaugeas0 package available, you can use the Apache plugin. This automates both obtaining and installing certs on an Apache webserver. To specify this plugin on the command line, simply include --apache.

Webroot¶

If you’re running a local webserver for which you have the ability to modify the content being served, and you’d prefer not to stop the webserver during the certificate issuance process, you can use the webroot plugin to obtain a cert by including certonly and --webroot on the command line. In addition, you’ll need to specify --webroot-path or -w with the top-level directory (“web root”) containing the files served by your webserver. For example, --webroot-path /var/www/html or --webroot-path /usr/share/nginx/html are two common webroot paths.

If you’re getting a certificate for many domains at once, the plugin needs to know where each domain’s files are served from, which could potentially be a separate directory for each domain. When requested a certificate for multiple domains, each domain will use the most recently specified --webroot-path. So, for instance,

letsencrypt certonly --webroot -w /var/www/example/ -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net

would obtain a single certificate for all of those names, using the /var/www/example webroot directory for the first two, and /var/www/other for the second two.

The webroot plugin works by creating a temporary file for each of your requested domains in ${webroot-path}/.well-known/acme-challenge. Then the Let’s Encrypt validation server makes HTTP requests to validate that the DNS for each requested domain resolves to the server running letsencrypt. An example request made to your web server would look like:

66.133.109.36 - - [05/Jan/2016:20:11:24 -0500] "GET /.well-known/acme-challenge/HGr8U1IeTW4kY_Z6UIyaakzOkyQgPr_7ArlLgtZE8SX HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Note that to use the webroot plugin, your server must be configured to serve files from hidden directories. If /.well-known is treated specially by your webserver configuration, you might need to modify the configuration to ensure that files inside /.well-known/acme-challenge are served by the webserver.

Standalone¶

To obtain a cert using a “standalone” webserver, you can use the standalone plugin by including certonly and --standalone on the command line. This plugin needs to bind to port 80 or 443 in order to perform domain validation, so you may need to stop your existing webserver. To control which port the plugin uses, include one of the options shown below on the command line.

• --standalone-supported-challenges http-01 to use port 80
• --standalone-supported-challenges tls-sni-01 to use port 443

The standalone plugin does not rely on any other server software running on the machine where you obtain the certificate. It must still be possible for that machine to accept inbound connections from the Internet on the specified port using each requested domain name.

Manual¶

If you’d like to obtain a cert running letsencrypt on a machine other than your target webserver or perform the steps for domain validation yourself, you can use the manual plugin. While hidden from the UI, you can use the plugin to obtain a cert by specifying certonly and --manual on the command line. This requires you to copy and paste commands into another terminal session, which may be on a different computer.

Nginx¶

In the future, if you’re running Nginx you can use this plugin to automatically obtain and install your certificate. The Nginx plugin is still experimental, however, and is not installed with letsencrypt-auto. If installed, you can select this plugin on the command line by including --nginx.

Third-party plugins¶

These plugins are listed at https://github.com/letsencrypt/letsencrypt/wiki/Plugins. If you’re interested, you can also write your own plugin.

Running with Docker¶

Docker is an amazingly simple and quick way to obtain a certificate. However, this mode of operation is unable to install certificates or configure your webserver, because our installer plugins cannot reach it from inside the Docker container.

You should definitely read the Where are my certificates? section, in order to know how to manage the certs manually. https://github.com/letsencrypt/letsencrypt/wiki/Ciphersuite-guidance provides some information about recommended ciphersuites. If none of these make much sense to you, you should definitely use the letsencrypt-auto method, which enables you to use installer plugins that cover both of those hard topics.

If you’re still not convinced and have decided to use this method, from the server that the domain you’re requesting a cert for resolves to, install Docker, then issue the following command:

sudo docker run -it --rm -p 443:443 -p 80:80 --name letsencrypt \
            -v "/etc/letsencrypt:/etc/letsencrypt" \
            -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
            quay.io/letsencrypt/letsencrypt:latest auth

and follow the instructions (note that auth command is explicitly used - no installer plugins involved). Your new cert will be available in /etc/letsencrypt/live on the host.

Operating System Packages¶

FreeBSD

• Port: cd /usr/ports/security/py-letsencrypt && make install clean
• Package: pkg install py27-letsencrypt

OpenBSD

• Port: cd /usr/ports/security/letsencrypt/client && make install clean
• Package: pkg_add letsencrypt

Arch Linux

sudo pacman -S letsencrypt letsencrypt-apache

Debian

If you run Debian Stretch or Debian Sid, you can install letsencrypt packages.

sudo apt-get update
sudo apt-get install letsencrypt python-letsencrypt-apache

If you don’t want to use the Apache plugin, you can omit the python-letsencrypt-apache package.

Packages for Debian Jessie are coming in the next few weeks.

Fedora

sudo dnf install letsencrypt

Gentoo

The official Let’s Encrypt client is available in Gentoo Portage. If you want to use the Apache plugin, it has to be installed separately:

emerge -av app-crypt/letsencrypt
emerge -av app-crypt/letsencrypt-apache

Currently, only the Apache plugin is included in Portage. However, if you want the nginx plugin, you can use Layman to add the mrueg overlay which does include the nginx plugin package:

emerge -av app-portage/layman
layman -S
layman -a mrueg
emerge -av app-crypt/letsencrypt-nginx

When using the Apache plugin, you will run into a “cannot find a cert or key directive” error if you’re sporting the default Gentoo httpd.conf. You can fix this by commenting out two lines in /etc/apache2/httpd.conf as follows:

Change

<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so
</IfDefine>

to

#<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so
#</IfDefine>

For the time being, this is the only way for the Apache plugin to recognise the appropriate directives when installing the certificate. Note: this change is not required for the other plugins.

Other Operating Systems

OS packaging is an ongoing effort. If you’d like to package Let’s Encrypt client for your distribution of choice please have a look at the Packaging Guide.

From source¶

Installation from source is only supported for developers and the whole process is described in the Developer Guide.

Comparison of different methods¶

Unless you have a very specific requirements, we kindly ask you to use the letsencrypt-auto method. It’s the fastest, the most thoroughly tested and the most reliable way of getting our software and the free SSL certificates!

Beyond the methods discussed here, other methods may be possible, such as installing Let’s Encrypt directly with pip from PyPI or downloading a ZIP archive from GitHub may be technically possible but are not presently recommended or supported.

Footnotes