How to Request, Generate & Setup Free Let’s Encrypt SSL Certificate
After downloading and installing Let’s Encrypt client on your web host, you’re ready to create and set up the free SSL certificates signed by Let’s Encrypt. The SSL certificates can be used to secure the websites with HTTPS connection for websites that are powered by variety of web servers such as Apache HTTPD web server, Nginx, IIS, lighttpd and etc.
Note
Let’s Encrypt client supports a number of different plugins that can be used to obtain and/or install certificates. However, not all plugins are supported on all system, especially “installer” plugins that can install a cert.
For example, Apache plugin for Let’s Encrypt currently only supports Apache 2.4 running on a Debian-based OS with version 1.0+ of the libaugeas0 package.
Follow the following guide to create and generate the free Let’s Encrypt SSL Certificate, and then install and setup the SSL certificate for your websites. The guide will make use of common “authenticator” plugins which should available on all systems by default, which make available different ways of verification of ownership.
Tip
You can check which plugins are installed by issuing the following command:
letsencrypt plugins
letsencrypt-auto accepts the same flags as letsencrypt and can be used interchangeably; letsencrypt-auto installs all of its own dependencies and updates the client code automatically, and thus it’s comparatively slower and larger than letsencrypt.
For Let’s Encrypt client obtained manually the comes with letsencrypt-auto, the client (letsencrypt binary) is available inside the virtual environment it created: /home/user/.local/share/letsencrypt/bin/letsencrypt.
Web Root Verification
If you have a running webserver for which you have the ability to modify the content being served, and you prefer not to stop the webserver during the certificate issuance process, the webroot plugin can automatically create the response to the ACME challenge.
Web root verification must run on the same system that matches the A record for the domain. It 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.
Example above illustrates getting a certificate for many domains at once through webroot plugin where each domain is located at separate directory. When requested a certificate for multiple domains, each domain will use the most recently specified –webroot-path preceding it.
Note
If multiple domains are listed, all domains will be included as SubjectAltNames in a single certificate.
Apache Verification
If you are running Apache 2.4 on a Debian-based OS with version 1.0+ of the libaugeas0 package available, use the following command with Apache plugin to automate both obtaining and installing certs on an Apache webserver.
The advantage of using Apache or nginx installers is that both performs the certificate management automatically, which is useful for renewal.
Standalone Verification
Standalone verification uses a standalone webserver to automatically responds to the challenge to obtain a cert. The downside of this method is that the existing web server must be temporarily stopped as Let’s Encrypt standalone webserver must bind to port 80 or 443 in order to perform domain validation. The advantage is that
The IP address requesting verification of standalone web server must match the A record for the domain requested, so the command has to run on the target web server.
To use HTTPS port 443 verification, change the switch of –standalone-supported-challenges to the following:
--standalone-supported-challenges tls-sni-01 to use port 443
Manual Verification
Manual verification allows you to run the LetsEncrypt client on a separate system from the web server which hosts the domains which certificates are required.
As it’s manual generation of SSL certificate, the Let’s Encrypt client will prompt for a secret per domain to be stored at specific locations. Run the following commands to set the secret location.
cd /var/www/html
mkdir -p .well-known/acme-challenge
echo "random strings" > .well-known/acme-challenge/random-file-name
The specific location storing the secret must be accessible through A record in the DNS, through it must be created within the domain’s web root. Change the folder location in the command accordingly.
Once Let’s Encrypt ACME server manages to test and match the site with the secret provided, Let’s Encrypt will provide the certificate.
Let's Encrypt Configuration File
You can also put all common Let’s Encrypt settings in a configuration file instead of typing it every time. To do so, create a file named cli.ini. An example of cli.ini is as follow:
# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
# Register with the specified e-mail address
email = [email protected]
# Uncomment and update to generate certificates for the specified domains.
# domains = example.com, www.example.com
# Use a text interface instead of ncurses
text = True
# Use the standalone authenticator on port 443
authenticator = standalone
standalone-supported-challenges = tls-sni-01
# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
# authenticator = webroot
# webroot-path = /usr/share/nginx/html
# If a certificate already exists for the requested domains, renew it now,
# regardless of whether it is near expiry.
renew-by-default = True
# Agree to the Let's Encrypt Subscriber Agreement
agree-tos = True
Place the cli.ini in /etc/letsencrypt/cli.ini, $XDG_CONFIG_HOME/letsencrypt/cli.ini or ~/.config/letsencrypt/cli.ini (if $XDG_CONFIG_HOME is not set). You can also specify the path to the configuration file with –config or -c switch. For example:
The email address is used only if you lose the account details and for recovery. This will allow you to verify your identity to revoke a certificate and request a new one.
Set Up Apache HTTPD Web Server with Let’s Encrypt SSL Certificate
Let’s Encrypt creates the SSL certificates in /etc/letsencrypt/live/domain_name directory. For example, for Tech Journey, it’s created in /etc/letsencrypt/live/techjourney.net folder. Essentially, 4 files are generated:
privkey.pem: Private key for the certificate (SSLCertificateKeyFile for Apache and ssl_certificate_key for Nginx)
cert.pem: Server certificate only (SSLCertificateFile for Apache < 2.4.8)
chain.pem: All certificates that need to be served by the browser excluding server certificate, i.e. root and intermediate certificates only (SSLCertificateChainFile for Apache = 1.3.7)
fullchain.pem: All certificates, including server certificate, i.e. concatenation of chain.pem and cert.pem (SSLCertificateFile for Apache >= 2.4.8 and ssl_certificate for Nginx)
It’s recommended to keep all SSL certificates inside its original directory for easy maintenance and renewal, instead of moving it to another location. Thus, whenever possible, point the web server configuration to directly make use of the files and create symlinks to the right location.
An example configuration for mod_SSL of Apache HTTPD web server running virtual hosts, where symbolic links are required:
LK is a technology writer for Tech Journey with background of system and network administrator. He has be documenting his experiences in digital and technology world for over 15 years.Connect with LK through Tech Journey on Facebook, Twitter or Google+.
