McGregor, Donald (Don) (CIV)
Child pages
  • letsencrypt
Skip to end of metadata
  • Created by Unknown User (mcgredo), last modified on Apr 20, 2017
Go to start of metadata

LetsEncrypt (https://letsencrypt.org/) is an effort to make SSL encryption of web servers free, easy and ubiquitous.

 

Important Note 

LetsEncrypt does not issue certificates to any domain in .mil. .mil is on their blacklist, along with some other domains, such as paypal. Letsencrypt calls this a "high risk certificate request" and states that "The '.mil' TLD and its subdomains will always be considered high risk and under no circumstances will the CA issue certificates for them." So don't bother trying to get a certificate from them for a .mil host. The domain nps.edu works, though. The web server for which you are getting a certificate has to be publicly visible from outside NPS because as part of the authentication process the letsencrypt server contacts the web server for which a certificate is being requested. If they can't contact the server from outside NPS then no certificate will be issued.

Intro

Traditionally, encrypting web server traffic via HTTPS involved getting an SSL certificate. You could get a commercial certificate from a provider such as godaddy, Thawte, RapidSSL, or DigiCert, or a government SSL certificate obtained from the DoD Public Key Infrastructure (PKI). Obtaining a certificate is error-prone because requesting the certificate is a step that requires human intervention, often by humans not directly managing the host.  To obtain a commercial certificate this requires a trip through the purchasing office, and filling out a bunch of forms. The whole cycle is just an enormous hassle, with multiple approvals and coordination required. Worse, I've often had to talk the person with credit card purchase authority through the button-ology of a web site to buy the certificate. You can easily burn hours on this task. For us government people, we can't buy a commercial certificate valid for a period longer than a year, because it's a service and we can't commit to a service for longer than a year at a time, or at least that's the story I've heard from purchasing. This means the whole purchasing drill and certificate re-issue crops up again a few months later when the certificate expires, and if you're running multiple web servers it will be a near-constant affair that just ruins your day. It's an unending Sisyphean task. If a certificate update notice falls through the cracks you wind up with an expired certificate on a production server, and have to do a fire drill to get a new certificate.

The Internet Security Research Group, run by a number of internet luminaries, (https://letsencrypt.org/isrg/ and https://letsencrypt.org/sponsors/) launched an effort to simplify and automate the update process, as well as making it free. The overall objective is to make the internet more secure by encrypting all web traffic, but it has the significant benefit for system administrators in that the certificate re-issue process can be automated.

A major impediment to free certificates is proving that the person requesting the certificate really controls the web server's domain; it would be bad if anyone could request a seemingly valid certificate for Microsoft or Bank of America. https://letsencrypt.org/how-it-works/ is a page that describes the process for authentication. Essentially, a protocol is established that proves the person requesting the certificate controls the web server at the URL listed.

Another question is what web browsers will recognize the certificate issued. Certificates are like personal ID cards: they're not all created equal. You may trust a driver's license if someone presents that when trying to cash a check, but you won't trust a club membership card issued by Lucky's grocery store to prove that the person really is who they say they are. Web browsers are the same way about who they trust, where the "who" is a web certificate. Web browsers downloaded from the vendor, such as Mozilla, Google Chrome, or Microsoft, have a list of certificate authorities that issue certificates that the web browser will trust by default. They'll recognize a certificate issued by GoDaddy, Thawte, or the China Internet Network Information Center (Run by the People's Republic of China!) but not one from Joe-Bob's Certificates LLC. This creates a problem with the installed base, unless you've got a time machine. A brand new certificate authority started by letsencrypt.org wouldn't be recognized by default in a web browser that was shipped in 2005. You can add new certificate authorities to the old web browser, just as you can by adding the DoD certificates to IE or Firefox, but that's a configuration problem that will hopelessly confuse users. LetsEncrypt solved this by repurposing an existing certificate authority that has been recognized by browsers for a long time. https://letsencrypt.org/docs/certificate-compatibility/ has a list of browsers that recognize the LetsEncrypt certificate authority. Coverage is good. Basically everything since Windows XP, and at that most deployed Windows XP, will recognize the LetsEncrypt CA. Which means that nearly all web browsers in use will trust a certificate issued by letsencrypt.

The DoD will issue certificates to .edu hosts, but the certificate will not be recognized by most browsers out of the box. A commercial certificate authority such as letsencrypt.org is better in this respect–the people visiting your site don't need to configure anything on their host in order to view the site. Also, remember that letsencrypt.org will not issue certificates to any .mil host. So .edu and .org sites work well with letsencrypt, but .mil sites will not work at all. .edu, .org, and .mil sites will work with DoD PKI, but you have to remember to re-up the certs before they expire, and any one visiting your site will have to install support for DoD PKI in their browser.

How To on RHEL 6/CentOS 6

You'd think that apache on RHEL 6 would be easy to deploy to with LetsEncrypt, but you would be wrong. The basic instructions are here: https://community.letsencrypt.org/t/redhat-centos-6-x-users-need-python-2-7/2190, https://community.letsencrypt.org/t/redhat-centos-6-x-users-need-python-2-7/2190 , or https://certbot.eff.org/#centosrhel6-apache.

RHEL6/CentOS6 has an ancient version of Python, V 2.6, but the LetsEncrypt deployment scripts require Python 2.7 at least. You can't uninstall Python 2.6 because it's needed for the yum package manager, which maintains packages for the whole operating system. So you need to install Python 2.7 in parallel with the existing, default Python package.  

Make sure the epel repo is installed. Something like this:

wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm

In RHEL 6 you'll also need to enable an update channel to get a supporting package.

rhn-channel --add --channel=rhel-x86_64-workstation-optional-6

This is to get the package libffi-devel. Annoyingly, you need to provide a RHN username and password to add this channel, and that's controlled by the site administrator.

Install the IUS repository. For RHEL 6:

wget https://rhel6.iuscommunity.org/ius-release.rpm
sudo rpm -Uvh iusrelease*.rpm

or for CentOS6:

wget https://centos6.iuscommunity.org/ius-relase.rpm
sudo rpm -Uvh iusrelease*.rpm

Install Python 2.7 alongside the default version:

yum -y install python27 python27-devel python27-pip python27-setuptools python27-virtualenv --enablerepo=ius

Then download and install the letsencrypt software. The git clone operation retrieves the software. The sed operation does a search and replace on the name of the python executable, from "python" to "python2.7" in the letsencrypt script.

cd /usr/local
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
sed -i "s|--python python2|--python python2.7|" letsencrypt-auto
 

From there you can just run the letsencrypt script, with the "apache" argument to install the config files for apache.

./letsencrypt-auto --apache 

Renewal

Life is better without firedrills. You don't want to discover expired certificates on your web servers. Since the process of getting new certificates can be automated, just write a crontab task to put certificate renewal on autopilot.

23 23 17 * * /opt/letsencrypt/letsencrypt-auto renew --pre-hook "service httpd stop" --post-hook "service httpd start" >> /var/log/le-renew.log

if you want to get fancier. 

That runs the letsencrypt-auto renew script once a month, on the 17th, at 11:23 PM. If the certificate is valid for less than 30 days then the script will renew it (ie, get a new certificate), based on the information saved in /etc/letsencrypt/renewal. Then it stops and reloads apache so apache reads the new certificate and can present it to users. Of course if in the meantime you've screwed up your config file somehow, then it will fail on the restart.

Alternative Method

That's the semi-official way to do it, but there are other script packages that do the same thing. Why use other packages? RHEL-5 has problems with letsencrypt because RHEL5/CentOS5 uses an old version of OpenSSL. You can't replace or use an alternative version of OpenSSL, because it's too deeply embedded in the structure of all the other packages that use it. See above for the problems of using the letsencrypt-auto script on RHEL6. Good news, though. LetsEncrypt is using a proposed (as of this writing) IETF protocol, and other client scripts exist. For example, the one at https://github.com/Neilpang/acme.sh .  

Generally this works more transparently than the letsencrypt scripts above. 

There's a list of packages that implement the ACME protocol at https://letsencrypt.org/docs/client-options/ .

With acme.sh, roughly:

The --install sets up acme and add a cronjob entry. The --issue creates a certificate for the web server. Stopping the apache server and then using the --tls and --standalone options runs a simple https web server that acts as the authentication server; this simplifies having to put something in the content so the issuing authority can confirm that you control the domain. The web server run by acme.sh is more straightforward on permissions and all that jazz. Restart the standard apache server after authentication.
When the --issue command is run it copies the key, certificate file, and CA chain to the /root/.acme.sh directory. You don't want the apache config file pointing to the files in that location. So, edit the /etc/httpd/config.d/ssl.conf file, and point the certificate, private key, and full chain file names in the directives to a known location. The --install-cert command will copy the files from the /root/.acme.sh directory to the specified location, in this case to /etc/httpd/certificates. 
When the cron job runs it will check to see if the certificate is close to expiration; if so it will renew it.

Summary

You get a web SSL certificate for free, and it gets renewed without human intervention. You don't have to deal with the paperwork hassle, and you avoid all the paperwork associated with purchasing.

 

 

  • No labels