Recipe for Let’s Encrypt on a Library OPAC Server

enterpriseThis post is part of a series about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  This  recipe will be describing how I installed certificates from Let’s Encrypt on a library OPAC server, more specifically an Apache Tomcat web application called Enterprise from SirsiDynix which is installed on a local server running CentOS 5.  Enterprise is actually a discovery service  that it can provide a single search interface across multiple collections, but our instance is focused on just the library catalog.

Note: these instructions are for Enterprise installed on a local server, if your Enterprise server is hosted by SirsiDynix, you would need to work with them to install HTTPS certificates.

We will be installing certificates on a test server for Enterprise.  Our production Enterprise server uses custom javascripts that make calls to a Web Services API  server to integrate real-time availability from the library management system into the search results.  We can’t move the production Enteprise server to HTTPS until after we have moved the Web Services API  server to HTTPS because modern web browsers will not allow insecure content to be embedded into a secure web page.  Plus what’s the point of having a test server if you just ignore it and make major changes to production?

Here are the overall steps on a local Enterpise server that you have shell access to with root or appropriate sudo privileges.

  • Get the client application.
  • Use the client application to generate certificates.
  • Configure Enterprise to use the certificates.
  • Set up a routine for renewal of certificates.

Get the Client Application

letsencryptLet’s Encrypt recommends using a client application called certbot to obtain certificates.   For a number of distros (Ubuntu, ArchLinux, Gentoo, CentOS RHEL 7), the client is available via the common package manager for that distro and can be installed with one command.  For CentOS 6, you have to take a few extra steps (see previous post).  But our server is still on CentOS 5 (I know, I know…but it’s not end-of-life until March 2017) which will present several additional challenges.

  • Create a directory for where the certbot client will live, this can be anywhere but I selected /usr/local/ and named the directory letsencrypt.
$ sudo mkdir /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
  • Download the certbot client and make it executable.
$ sudo wget https://dl.eff.org/certbot-auto
$ sudo chmod a+x certbot-auto
  • Enable the EPEL (Extra Packages for Enterprise Linux) repository.  This will make additional dependencies available to the certbot client  Because we are on CentOS 5, we have to download and install an RPM package.
$ sudo wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-5.noarch.rpm
$ sudo rpm -Uvh epel-release-latest-5*.rpm
  • Install python 2.6 as a requirement for the certbot client.  CentOS 5 has python 2.4 installed but certbot requires python 2.6 or higher.  Trying to upgrade the builtin python 2.4 on CentOS 5 leads to dependency hell (trust me on this one), instead we will install separate version of python 2.6 and use an environmental variable to tell cerbot to use this version.
$ sudo yum install python26 python26-devel

Generate Certificates

The certbot client is actually a script that performs a number of tasks, see this previous post for more details.

  • Stop httpd service so that the certbot client bind to the web server ports prove to Let’s Encrypt that you control this domain.
$ sudo service httpd stop
  • Run the certbot client to install certificates in manual mode.
$ cd /usr/local/letsencrypt
$ sudo LE_PYTHON=python2.6 ./certbot-auto --standalone --standalone-supported-challenges http-01 certonly -d jlc-web-test.uaa.alaska.edu

The LE_PYTHON=python2.6 tells certbot to use that version of python instead of the default 2.4.  Because CentOS 5 has an old version of openssl (0.9), we can’t use the –apache switch event though this is an apache server.  Instead we have to use –standalone switchwhich tells certbot to bind temporarily to the web server ports and install the certificates in the /etc/letsencrypt/ directory.  In addition, because openssl 0.9 does not support TLS-SNI challenges, we have to use the option –standalone-supported-challenges http-01 to specify  port 80.

  • Answer the questions the client will ask and wait for it to finish.
email address?
I put in my email address.

At this point, the certbot client will abort with an error because of the old version of openssl that is installed does not support the SSL_set_tlsext_host_name attribute.

An unexpected error occurred:
 AttributeError: 'module' object has no attribute 'SSL_set_tlsext_host_name'
 Please see the logfiles in /var/log/letsencrypt for more details.
  • Look at the log file to see the error.
$ sudo cat /var/log/letsencrypt/letsencrypt.log

File "/root/.local/share/letsencrypt/lib/python2.6/site-packages/OpenSSL/SSL.py", line 1237, in set_tlsext_host_name
 _lib.SSL_set_tlsext_host_name(self._ssl, name)
 AttributeError: 'module' object has no attribute 'SSL_set_tlsext_host_name'
  • Edit the certbot client using nano (or your favorite text editor) at the appropriate line number to work around this by adding try: before the line and then a second line with except:pass. That’s right, we are going to hack tweak the client.
$ sudo nano +1237 /root/.local/share/letsencrypt/lib/python2.6/site-packages/OpenSSL/SSL.py

try: _lib.SSL_set_tlsext_host_name(self._ssl, name)
 except: pass

This makes getting the SSL_set_tlsext_host_name attribute optional instead of mandatory.  As far as I can tell, getting this attribute is just is just part of a standard initialization proceedure and is not needed to generate the certificates.

  • Run the certbot client again.
$ sudo LE_PYTHON=python2.6 ./certbot-auto --standalone --standalone-supported-challenges http-01 certonly -d jlc-web-test.uaa.alaska.edu
  • Answer the questions the client will ask and wait for it to finish.
email address?
I put in my email address.
Agree to Let's Encrypt's terms
yes
  • Start the  httpd service again.
$ sudo service httpd start

Configure Enterprise to Use the Certificates

There are two possible methods for installing HTTPS certificates for Apache Tomcat depending on how the application is configured:

  • Direct access – configure Tomcat to use a Java Key Store that houses the certificates
  • Proxy access – configure Apache to use the certificates

Enterprise uses Apache to proxy access to the Tomcat application so we use the second method.  In our next post on installing Let’s Encrypt certificates on a Web Services API  Apache Tomcat server,  we will cover configuring Tomcat for direct access.

  • Create a minimal SSL conf for Apache that points to the Let’s Encrypt certificates.
$ sudo nano /etc/httpd/conf.d/ssl.conf

LoadModule ssl_module modules/mod_ssl.so
 Listen 443
 AddType application/x-x509-ca-cert .crt
 AddType application/x-pkcs7-crl    .crl
 SSLPassPhraseDialog  builtin
 SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
 SSLSessionCacheTimeout  300
 SSLMutex default
 SSLRandomSeed startup file:/dev/urandom  256
 SSLRandomSeed connect builtin
 SSLCryptoDevice builtin

<VirtualHost _default_:443>
 SSLEngine On
 SSLProtocol  all -SSLv2 -SSLv3
 SSLHonorCipherOrder on
 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

SSLCertificateFile /etc/letsencrypt/live/jlc-web-test.uaa.alaska.edu/cert.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/jlc-web-test.uaa.alaska.edu/privkey.pem
 SSLCertificateChainFile /etc/letsencrypt/live/jlc-web-test.uaa.alaska.edu/chain.pem

ServerName jlc-web-test.uaa.alaska.edu
 </VirtualHost>
  • Restart Apache service
$ sudo service httpd restart
  • Configure Enterprise to use HTTPS by logging into the database that is part of the web application and changing a property value.
$ sudo psql -U discovery
discovery=# UPDATE system_property SET property_value='true' WHERE property_key='PLATFORM:IS_HTTPS';
discovery=# \q
$
  • Restart the tomcat and jboss applications for Enterprise.
$ sudo /etc/init.d/discovery-tomcat stop
$ sudo /etc/init.d/discovery-server stop
$ sudo /etc/init.d/discovery-server start
$ sudo /etc/init.d/discovery-tomcat start
  • jlc-web-test-sslabsTest the certificates to make sure they are installed correctly for each domain.
https://www.ssllabs.com/ssltest/analyze.html?d=jlc-web-test.uaa.alaska.edu&latest

Note: The grade is a C rating because the openssl 0.9 does not support TLS 1.2 . This rating will improve when we upgrade from CentOS 5 to 7.

That’s it, our library OAPC server is now using free HTTPS certificates issued by Let’s Encrypt.  The challenges we ran into were the result of being on CentOS 5 with out-of-date versions of python and openssl.  If our server was on an up-to-date OS, this would have been very straight forward.

Certificate Renewal

Let’s Encrypt will only issue certificates for 90 days for some good reasons but this comes as quite a shock to administrators who are used to  1-3 year renewal periods.  The idea is that renewal will be automatic so that you will only need to manually deal with certificates when first issuing them or when making changes to domain names.

  • Screenshot - 07152016 - 05:38:58 PMPerform a dry-run to renew certificates without making a real request.  You should get a message that the test succeeded.
$ sudo service httpd stop
$ cd /usr/local/letsencrypt
$ sudo LE_PYTHON=python2.6 ./certbot-auto renew --dry-run
$ sudo service httpd start
  • Add a cron or systemd job to run the command automatically.  The certificates will only renew if they are going to expire in 30 days or less.  Let’s Encrypt recommends running the renewal command twice a day.  I’m old school so decided to use crontab.

$ sudo crontab -e

Here is an example entry to run renewal once a day at 4:25am.
25 04 * * * /usr/local/letsencrypt/LE_PYTHON=python2.6 ./certbot-auto renew –quiet

Note: because the certbot client automatically updates itself with a newer version if available, we might have to tweak the client again to avoid the SSL_set_tlsext_host_name error, but this  potential problem will go away once we upgrade to CentOS 7.

Next Post

The next post in the series will be on installing Let’s Encrypt certificates on a Web Services API  Apache Tomcat server.

Recipe for Let’s Encrypt on Standalone EZproxy Server

This post is part of a series about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  This  recipe will be describing how I installed certificates from Let’s Encrypt on a standalone EZproxy server that provides authentication and access to online resources.

Note: if your library uses the hosted EZproxy service, certificate management is provided by OCLC.

ezproxy

 

letsencryptEZproxy can be configured to use SSL  to provide access  to content from secure URLs that begin with https://.  If your EZproxy configuration uses proxy by hostname you will need a subdomain certificate for each secure URL that can be accessed.  The easiest way to handle this is to install certificates which support wildcard for multiple subdomains. While Let’s Encrypt does not support wildcard certificates at this time, it does support issuing up to 100 subdomains on a single certificate.  This means that Let’s Encrypt is a good solution for standalone Ezproxy servers that access less than 100 secure URLs.

For our library, we will continue to use purchased certificates that support wildcard for our main EZproxy service and use Let’s Encrypt to install certificates on a second EZproxy service for the Alaska Medical Library, a unit inside the main library, that provides access to content from a handful of providers.

Here are the overall steps on a standalone Linux EZproxy server that you have shell access to with root or appropriate sudo privileges.

  • Get the client application.
  • Use the client application to generate certificates.
  • Configure EZproxy to use the certificates.
  • Set up a routine for renewal of certificates.

Get the Client Application

Let’s Encrypt recommends using a client application called certbot to obtain certificates.   For a number of distros (Ubuntu, ArchLinux, Gentoo, CentOS RHEL 7), the client is available via the common package manager for that distro and can be installed with one command.  Our server is still on CentOS 6, so we have a few extra steps.

  • Enable the EPEL (Extra Packages for Enterprise Linux) repository.  This will make additional dependencies available to the certbot client.
$ sudo yum install epel-release
  • Create a directory for where the certbot client will live, this can be anywhere but I selected /usr/local/ and named the directory letsencrypt.
$ sudo mkdir /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
  • Download the certbot client and make it executable.
$ sudo wget https://dl.eff.org/certbot-auto
$ sudo chmod a+x certbot-auto

Generate Certificates

The certbot client is actually a script that performs a number of tasks, see this previous post for more details.

  • Stop EZproxy service so that the certbot client can use port 80 to prove to Let’s Encrypt that you control this domain.
$ sudo service ezproxy stop

Note: if this command does not work,  use the ./ezproxy -si command to install the start up scripts.

  • Run the certbot client to install certificates in manual mode for two domain names ( one the EZproxy server, the other for a secure content subdomain ).  The –standalone switch tells certbot to bind temporarily to port 443 and install the certificates in the /etc/letsencrypt/ directory.  If we had additional secure content subdomains, we could add them to the line with additional -d switches.
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto --standalone certonly -d amlproxy.consortiumlibrary.org -d naturalmedicines.therapeuticresearch.com.amlproxy.consortiumlibrary.org
  • Answer the questions the client will ask and wait for it to finish.
email address?
I put in my email address.
  • Start the  EZproxy service again.
$ sudo service ezproxy start

Configure EZproxy to Use the Certificates

  • Enable port 443 for SSL
Edit config.txt and add the line:

    LoginPortSSL 443

Restart the EZproxy service

    $ sudo service ezproxy restart
  • Import certificates into EZproxy.
Login to the EZproxy admin page.

From the EZproxy administration page, under the Miscellaneous heading, 
click on Manage SSL (https) certificates and select Import certificates

Copy & paste the contents of the file
/etc/letsencrypt/live/amlproxy.consortiumlibrary.org/cert.pem 
into the Certificate text box

Copy & paste the contents of the file
/etc/letsencrypt/live/amlproxy.consortiumlibrary.org/privkey.pem 
into the Key text box

Click the Import button

On the Certificate Details page

Copy & paste the contents of the file 
/etc/letsencrypt/live/amlproxy.consortiumlibrary.org/chain.pem
into the Certificate Authority Chain (Intermediate Certificates) text box

Click Save Certificate Authority Chain button

Find the line of text that states 
To make this the active certificate for this server...
Type ACTIVATE in the box and click activate button

Import Existing SSL CertificateSSL Server Test_ amlproxy.consortiumlibrary

  • Test the certificates to make sure they are installed correctly for each domain.
https://www.ssllabs.com/ssltest/analyze.html?d=amlproxy.consortiumlibrary.org&latest
https://www.ssllabs.com/ssltest/analyze.html?d=naturalmedicines.therapeuticresearch.com.amlproxy.consortiumlibrary.org

Note: The grade is a C rating because the version of EZproxy  we are running (5.7.44) does not support TLS 1.2 .  We will probably need to upgrade at some point.

  • Enable secure logins and add directive for secure URL.
Add the following directive to the config.txt file to enable secure login:

     Option ForceHTTPSLogin

Add directive in the config.txt for the secure resource:

     H https://naturalmedicines.therapeuticresearch.com.amlproxy.consortiumlibrary.org

Restart EZproxy service

     $ sudo service ezproxy restart

That’s it, our EZproxy server is now using free HTTPS certificates issued by Let’s Encrypt for secure logins.

Certificate Renewal

Let’s Encrypt will only issue certificates for 90 days for some good reasons but this comes as quite a shock to administrators who are used to  1-3 year renewal periods.  The idea is that renewal will be automatic so that you will only need to manually deal with certificates when first issuing them or when making changes to domain names.  Unfortunately for the EZproxy server, we have one step that I have not been able to automate.

  • Stop the EZproxy service and perform a dry-run to renew certificates without making a real request.  You should get a message that the test succeeded.
$ sudo service ezproxy stop
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto renew --dry-run
$ sudo service ezproxy start
  • Add a cron or systemd job to run the commands automatically.  The certificates will only renew if they are going to expire in 30 days or less.  Let’s Encrypt recommends running the renewal command twice a day.  I’m old school so decided to use crontab.

$ sudo crontab -e

Here are example entries to stop EZproxy once a day at 4:20am, run renewal  at 4:25am, and start EZproxy at 4:30am.

20 04 * * * /etc/init.d/ezproxy stop

25 04 * * * /usr/local/letsencrypt/./certbot-auto renew –quiet

30 04 * * * /etc/init.d/ezproxy start

  • Import the certificates into EZproxy and activate them using the steps described earlier in this post.  I am not aware of a way to automate this part, so for now I will just set a calendar reminder and do this every 90 days.

Next Post

The next post in the series will be on installing Let’s Encrypt certificates on a library OPAC (SirsiDynix Enterprise) Tomcat Server on CentOS 5.

.

Recipe for Let’s Encrypt on Windows 2008 IIS Web Server

windowsserverThis post is part of a series about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  This  recipe will be describing how I installed certificates from Let’s Encrypt on a Windows 2008 IIS Web server that hosts two web applications.

  • A Web interface to an Inmagic database for Arctic Health Literature.
  • A search engine powered by DTSearch for the Arctic Health website.

These web applications provide content which is embedded into an external website called Arctic Health which recently moved to HTTPS.  Thus the web applications need to move to HTTPS to avoid insecure-content warnings or blocks.

letsencryptLet’s Encrypt provides both certificates and certbot, a client that makes installing and renewing the certificates as painless as possible for a number of Web servers and operating systems.  Unfortunately, certbot is not available for Windows so we will have to use one of the many many alternative clients.  I selected lets-encrypt-winsimple which does not have as many options as some other clients but is straight forward to use.  If you have a complex IIS server configuration you may want to select a different client.

Get the Client Application

Lets-encrypt-winsimple requires that you have .net framework 4.5 installed.  Our web applications are old and use .net frameworks 2.0.  Luckily you can run multiple versions of .net on the same server without issues.  Lets-encrypt-winsimple scans your IIS server for binds to determine the domain name.  We don’t have a bind for the domain name so we will need to create one.

  • Download and install .net framework 4.5.
Go to https://www.microsoft.com/en-us/download/details.aspx?id=30653
Choose the Download button
Choose the Run button
Make a cup of coffee
  • Add bind for default website in IIS for http to hostname web2.uaa.alaska.edu.
Under Administrative Tools, choose IIS Manager console
Open Internet Information Services (IIS) Manager
In the Connections pane, right click on the Default Web Site
Choose Edit Bindings
    Note: there is already a default binding (http 80 *) that we will leave in place 
    so that access to the server via IP address will still work.
Choose Add and create an additional binding
    Type:http
    Port:80
    IP address:All Unassigned
    Host name: web2.uaa.alaska.edu
  • Download the lets-encrypt-winsimple client
Download command line client letsencrypt-win-simple.v1.9.0
Go to https://github.com/Lone-Coder/letsencrypt-win-simple
Choose Clone or Download button
Choose Download Zip
Unzip the downloaded letsencrypt-win-simple.v1.9.0.zip
Move the letsencrypt-win-simple.v1.9.0 folder to where you want it to live
     In my case I am putting it into the current user folder C:\Users\Admin.

Install Certificates

Lets-encrypt-winsimple is a ACME client built in .net that performs a several tasks:

  • scans IIS bindings for host names;
  • connects to the Let’s Encrypt certificate authority to request certificates;
  • imports the certificate files into the Windows certificate store;
  • creates or update an https binding in IIS;
  • creates a task in Windows Task Schedule that will run each morning and update the certificates automatically every 60 days.

The client is a command line interface and there are a number of available options.

  • Run the lets-encrypt-winsimple client  to install certificates for the domain names defined in IIS (in this case only one, web2.uaa.alaska.edu).
Open a command prompt as administrator
C:\Users\Admin> cd letsencrypt-win-simple v1.9.0
C:\Users\Admin\letsencrypt-win-simple.v1.9.0> letsencrypt.exe
  • Screenshot - 06162016 - 02:03:23 PMAnswer the questions the client will ask and wait for it to finish.
Email address? 
     I put in my email address
Agree to Let's Encrypt terms of registration? 
     Y 
Which hosts do you want to get certificates for? 
     A for all hosts
Install certificates in Windows Certificate store? 
     Y
Add certificates to server software? 
     Y
Schedule automatic renewals? 
     Y
Specify user? 
     Y
Username? 
     admin
Password? 
     wouldn't you like to know
  • Screenshot - 06162016 - 02:57:36 PMTest the certificates to make sure they are installed correctly for each domain.
https://www.ssllabs.com/ssltest/analyze.html?d=web2.uaa.alaska.edu&latest

That’s it, our Web server is now using free HTTPS certificates issued by Let’s Encrypt.  It imported the certificates into the Windows certificate store and created a binding in IIS for https port 443 for host web2.uaa.alaska.edu.

We can now tell the folks managing the Arctic Health website to start using https://web2.uaa.alaks.edu instead of http://137.229.184.12 for embedded content.

Note: When I first ran the ssllabs test, the grade was an F because of the default settings for protocols and ciphers in IIS on Windows 2008.  I used a free, easy-to-use tool called IIS Crypto to tighten things up to a C rating.  Windows 2008 can not get a higher rating because it does not support TLS 1.2, that only became available in Windows 2008 R2 which is a separate product not a free upgrade.  At some point, we will need to upgrade but probably will go to Windows 2012 R2 or the not-yet-released Windows 2016.

Next Post

The next post in the series will be on installing Let’s Encrypt certificates on EZproxy on CentOS 6.

Recipe for Let’s Encrypt on CentOS 6 Apache Web Server

centosThis post is part of a series about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  We will cover migrating the server for our main website from commercially purchased HTTPS certificates to Let’s Encrypt certificates.

letsencryptSo why use Let’s Encrypt to install certificates on a server which was already running perfectly fine on purchased certificates?

  • To save money, every little bit helps.
  • To be able to reassign the purchased certificates (which support wildcard for multiple subdomains) to our Ezproxy server.  More on this in a future post in this series.
  • Cause, as in “cause I can.”  Put in a less cavalier way,  it allowed me to gain experience using Let’s Encrypt on a production server.  Its only fair that I  eat my own dogfood since I am advocating that libraries adopt Let’s Encrypt.

Let’s Encrypt provides both certificates and a set of tools to make installing and renewing the certificates as painless as possible.  Here are the overall steps on a Linux Apache Web server that you have shell access to with root or appropriate sudo privileges.

  • Get the client application.
  • Use the client application to install certificates.
  • Set up automatic renewal of certificates.

It was fast and painless to do this on an Apache server running on a modern Linux distro.  This will not be as true for some of the recipes I will be sharing later in the series.

Get the Client Application

Let’s Encrypt developed a client application that they initially called letsencrypt to automate many of the steps involved in issuing certificates and installing them correctly in the Web server.  In April this year, they released a new version of the client called certbot which will be maintained by the Electronic Frontier Foundation.  You will see instructions out on the Web that use the letsencrypt client, it is pretty much interchangeable with the certbot client.

Screenshot - 06142016 - 09:50:03 PMThe cerbot client is available for several types of web servers and common Linux distributions.  There are also alternative clients and methods that will allow you to install Let’s Encrypt certificates if the cerbot client does not fit your situation.  For a number of distros (Ubuntu, ArchLinux, Gentoo, CentOS RHEL 7), the client is available via the common package manager for that distro and can be installed with one command.  Alas, our server is still on CentOS 6, so we have a few extra steps.

  • Enable the EPEL (Extra Packages for Enterprise Linux) repository.  This will make additional dependencies available to the certbot client.
$ sudo yum install epel-release
  • Create a directory for where the certbot client will live, this can be anywhere but should probably be in /usr/local or /opt.  I selected /usr/local/ and named the directory letsencrypt.
$ sudo mkdir /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
  • Download the certbot client and make it executable.
$ sudo wget https://dl.eff.org/certbot-auto
$ sudo chmod a+x certbot-auto

Install Certificates

The certbot client is actually a script that performs a number of tasks:

  • examines your system and installs or updates any software dependencies that it needs (python, tlk, http modules, dev tools, etc.);
  • creates a virtual environment to work in;
  • connects to the Let’s Encrypt certificate authority to request certificates;
  • installs the certificates on the server and configures the Web service to use them.

Each time you run the client, it will auto-update itself as well as any software it depends on, so if you run any file integrity or intrusion detection software it will trip alarms.  Here is the log of what the certbot client installed the first time it ran on our server.  The client provides a lot of options and plugins.

  • Run the certbot client to install certificates for two domain names for an Apache server.
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto --apache -d consortiumlibrary.org -d www.consortiumlibrary.org
  • Answer the questions the client will ask and wait for it to finish.
email address?
I put in my email address.

location of ssl configuration files?
This defaulted correctly to /etc/httpd/conf.d/ssl.conf.

easy (http or https) or secure (only https)?
I selected easy.
  • Screenshot - 06142016 - 09:27:44 PMTest the certificates to make sure they are installed correctly for each domain.
https://www.ssllabs.com/ssltest/analyze.html?d=consortiumlibrary.org
https://www.ssllabs.com/ssltest/analyze.html?d=www.consortiumlibrary.org

That’s it, our Web server is now using free HTTPS certificates issued by Let’s Encrypt. It placed the new certificates in /etc/letsencrypt/live and made changes to the ssl.conf to point from our old certificates to our new ones.

We can now tell our commercial certificate authority to revoke our old certificates or to reassign them to another domain.

Certificate Renewal

Let’s Encrypt will only issue certificates for 90 days for some good reasons but this comes as quite a shock to administrators who are used to  1-3 year renewal periods.  The idea is that renewal will be automatic so that you will only need to manually deal with certificates when first issuing them or when making changes to domain names.  If this proves to be true, Let’s Encrypt with 90-day automated renewals will be less hassle than manually renewing commercial certificates each year.

  • Screenshot - 06142016 - 09:17:17 PMPerform a dry-run to renew certificates without making a real request.  You should get a message that the test succeeded.
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto renew --dry-run
  • Add a cron or systemd job to run the command automatically.  The certificates will only renew if they are going to expire in 30 days or less.  Let’s Encrypt recommends running the renewal command twice a day.  I’m old school so decided to use crontab.

$ sudo crontab -e

Here is an example entry to run renewal once a day at 4:25am.
25 04 * * * /usr/local/letsencrypt/./certbot-auto renew –quiet

Next Post

The next post in the series will be on installing Let’s Encrypt certificates on a Windows 2008 IIS Server.

 

Let’s Encrypt Cookbook

serveimageI am planning a series of blog posts about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  Let’s Encrypt is a certificate authority that issues free TSL certificates as part of a widespread campaign to move all web traffic to HTTPS and has a number of sponsors including the Electronic Frontier Foundation, Mozilla, Chrome, Cisco, Facebook, Automatic (the WordPress folks), and the American Library Association.  That’s right, ALA is a sponsor of this important initiative in order to help libraries move to HTTPS.

Let’s Encrypt also provides a set of tools to automate the installation and renewal of certificates.  The free tools and certificates became available in a beta version last November and moved out of beta status in April 2016.  Adoption has been rapid.  According to this article in Wired magazine:

  •  “The 1.8 million certificates Let’s Encrypt has issued to 3.8 million websites make it the third-largest certificate authority in the world”
  • “85 percent of those sites never had HTTPS before”
  • “All sites hosted on WordPress with custom URLs will now be encrypted by default using Let’s Encrypt’s certificates.”

Most libraries have never had HTPPS, and its time for that to change.  I plan to share my recipes for using Let’s Encrypt over the next week or two.  They are in essence “rough drafts” of what will hopefully become more polished How-to Guides that will be published more formally on the Choose Privacy Week website or somewhere else on the ALA website.  Here are the posts I have planned for servers:

Later in the summer, I will be tackling the following:

  • Best practices for preparing your website to migrate to HTTPS
  • Trying to install Let’s Encrypt certificates on ILS server
  • Trying to install Let’s Encrypt certificates on several different commercial Web hosting platforms
  • Trying to install Let’s Encrypt certificates on other types of servers (VPN, Squid proxy, mail)

So stay tuned!