Letsencrypt

	Work in Progress:
	This page is a Work in Progress. The contents off this page may be in flux, please have a look at this page history the to see list of changes.

	Skill level: Advanced
	The instructions on this page may require deviations from standard procedures. A good understanding of linux and Koozali SME Server is recommended.

	Warning:
	This procedure change the default certificates and could significantly compromise your server's security. Thorough understanding of linux system management is required. Proceed at your own risk

Introduction

Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic by a very simple system.

The certs delivered must be renewed every 3 months.

As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted in this topic at the letsencrypt.org forums.

If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Happy hacker CA", but it will allow you to validate the toolchain and workflow. To do this, add "--server https://acme-staging.api.letsencrypt.org/directory" to the letsencrypt commands below. See this post at the letsencrypt.org forums for more information.

The current status of the Letsencrypt services can be found on their status page.

Prerequisites

The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:

• www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.
• www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.
• Your SME Server is connected to the Internet.
• Ports 80 and 443 on your SME Server are open to the Internet--you aren't behind a firewall, or some ISP filtering, that would block them.

Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.

Make sure you've got this all set up correctly before continuing.

Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:

# config show modSSL

By default it would show:

modSSL=service
   TCPPort=443
   access=public
   status=enabled

If this shows any values for crt, key, or CertificateChainFile. If values are shown for any of these properties, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:

config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"

or to be sure, a copy of the complete configuration database (a good practice before any action such as manual changing of db values or installing a contrib):

config show > "/root/db_configuration_backup_$(date +%Y%m%d_%H%M%S)"

Installation

Multiple clients are available for the Letsencrypt services. The official client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. SME Server 9.0 and later, in the 64-bit versions, support the use of Software Collections, which allow installation of Python 2.7 alongside the default Python 2.6 installation.

Users of SME Server 8.x, or those who would prefer a more lightweight client, can use an alternative. Letsencrypt.sh, documented below, is a shell script that requires no further dependencies that aren't installed by default on the SME Server.

Installation of Official Client

For the installation of Letsencrypt, the initial generation of the certificates and periodically re-new the authority certificates, at minimum Python version 2.7 is required. By default SME Server comes with a lower version, but below instruction will enable you to install version 2.7 in a 'supported' way, next to the default SME Server Python version. The newly installed Python version 2.7 will then only be used (after initial installation) for the renewal of the certificates (periodically and mandatory every 3 months).

Follow the instructions at Software_Collections and the python related wiki page specifically. You need to add the scl-repository for Python 2.7 that can be found here

To install Python 2.7:

yum install python27 --enablerepo=scl-python27

You can download the latest Letsencrypt code from their Github page either via GIT or as a ZIP file.

To download via GIT do:

yum install git
cd /opt
git clone https://github.com/letsencrypt/letsencrypt.git

To download as a ZIP do:

wget https://github.com/letsencrypt/letsencrypt/archive/master.zip -P /opt
unzip /opt/master.zip -d /opt && mv /opt/letsencrypt-master /opt/letsencrypt
rm -f /opt/master.zip

To use Let's Encrypt run:

cd /opt/letsencrypt
service httpd-e-smith stop
scl enable python27 bash
./letsencrypt-auto certonly --standalone --email me@mydomain.co.uk -d test.firstdomain.co.uk -d seconddomain.co.uk -d www.seconddomain.co.uk
exit

Replacing email and domains as required. You should include every hostname that is hosted on your SME server, along with any aliases you use (e.g., www.yourdomain.tld, mail.yourdomain.tld, yourdomain.tld, www.yourotherdomain.tld, etc.). If it completes with no errors, it should tell you your certificate has been created. To confirm, do:

ls -l /etc/letsencrypt/live/test.firstdomain.co.uk

You should see something very similar to this:

lrwxrwxrwx 1 root root 43 Dec 16 17:08 cert.pem -> ../../archive/test.firstdomain.co.uk/cert1.pem
lrwxrwxrwx 1 root root 44 Dec 16 17:08 chain.pem -> ../../archive/test.firstdomain.co.uk/chain1.pem
lrwxrwxrwx 1 root root 48 Dec 16 17:08 fullchain.pem -> ../../archive/test.firstdomain.co.uk/fullchain1.pem
lrwxrwxrwx 1 root root 46 Dec 16 17:08 privkey.pem -> ../../archive/test.firstdomain.co.uk/privkey1.pem

If you do not see these files, stop. Troubleshoot the problem before proceeding. If you continue, you will break your web server any anything else that depends on SSL. If you do see these files, go ahead and configure SME with the certificates generated:

config setprop modSSL crt /etc/letsencrypt/live/test.firstdomain.co.uk/cert.pem
config setprop modSSL key /etc/letsencrypt/live/test.firstdomain.co.uk/privkey.pem
config setprop modSSL CertificateChainFile /etc/letsencrypt/live/test.firstdomain.co.uk/chain.pem
signal-event domain-modify; signal-event email-update; signal-event ibay-modify

	Note:
	We need to see if setting the above db variables disturbs other SME Server default functionality and contribs that work with certificates such as VPN solutions.

Once you've obtained your certificate and configured your server, test your server with a tool like SSLLabs.com to make sure it's working properly.

Installation of Letsencrypt.sh

Letsencrypt.sh is a lightweight alternative ACME client which will allow you to retrieve certificates from the Letsencrypt servers without needing to install any additional software on your server, other than git to download and install it. Begin by installing git:

yum install git

Then download the letsencrypt.sh client:

cd /etc
git clone https://github.com/lukas2511/letsencrypt.sh
mv letsencrypt.sh/letsencrypt.sh /usr/local/bin/

You'll need to create two configuration files for letsencrypt.sh.

cd letsencrypt.sh
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
nano -w domains.txt

In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:

domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org

Ctrl-X to exit, Y to save.

Second, you'll need to create the configuration file:

nano -w config.sh

It should look like this:

#!/bin/bash
# config.sh

WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/usr/local/bin/letsencrypt-hook.sh"
# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL="admin@yourdomain.com"

Ctrl-X to exit, Y to save.

You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.

nano /usr/local/bin/letsencrypt-hook.sh

Its contents should look like this:

#!/bin/bash

if [ $1 -eq "deploy_cert" ]; then
  KEY = $3
  CERT = $4
  CHAIN = $5
  /sbin/e-smith/db configuration setprop modSSL key $KEY
  /sbin/e-smith/db configuration setprop modSSL crt $CERT
# the next line isn't ideal, because letsencrypt.sh passes the path to fullchain.pem and not chain.pem, but it will still work
  /sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN
  /sbin/e-smith/signal-event domain-modify
  /sbin/e-smith/signal-event email-update
  /sbin/e-smith/signal-event ibay-modify
fi

Ctrl-X to exit, Y to save. Then make it executable:

chmod +x /usr/local/bin/letsencrypt-hook.sh

You'll also need to create a custom template fragment for Apache:

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME

The contents of that file should look like:

# Alias for letsencrypt
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

Again, Ctrl-X to exit, Y to save.

Expand the template and restart apache:

expand-template /etc/httpd/conf/httpd.conf
service httpd-e-smith restart

Now you're ready to run letsencrypt.sh and get your certificate.

letsencrypt.sh -c

The script will run for a moment and should report success. If it does, look in /etc/letsencrypt.sh/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run

config show modSSL

and make sure there are values set for crt, key, and CertificateChainFile.

As above, once you've obtained your certificate and configured your server, test your server with a tool like SSLLabs.com to make sure it's working properly.

Troubleshooting

Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:

config setprop modSSL crt (old value)
config setprop modSSL key (old value)
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)

If you did not have custom settings for modSSL, remove your changes with:

config delprop modSSL crt
config delprop modSSL key
config delprop modSSL CertificateChainFile 

Once you've made these changes, do:

signal-event post-upgrade
signal-event reboot

Renewal of the certificates

As part of the security of Letsencrypt the certificates must be renewed every 3 months.

Using the official client

The following script will automatically renew your certificate. Save it in a convenient place, for example, /opt/letsencrypt-renew.sh, and make sure to make it executable (chmod +x).

#!/bin/bash
/sbin/service httpd-e-smith stop
/opt/letsencrypt/letsencrypt-auto certonly --standalone --renew-by-default --email me@mydomain.co.uk \
 -d test.firstdomain.co.uk -d seconddomain.co.uk -d www.seconddomain.co.uk 
/sbin/e-smith/signal-event domain-modify
/sbin/e-smith/signal-event email-update
/sbin/e-smith/signal-event ibay-modify

Call this script by running

# scl enable python27 '/opt/letsencrypt-renew.sh'

You may want to set this up as a cron job to run every two months, to make sure your certificate doesn't expire. Please see Crontab_Manager contrib for an easy way to achieve this. Or, to set this from the command line, do the following:

mkdir -p /etc/e-smith/templates-custom/etc/crontab
nano /etc/e-smith/templates-custom/etc/crontab/sslrenew

The following example will run the renewal script at 22:48 on the third of every other month (Jan, Mar, May, etc.):

48 22 3 */2 * root scl enable python27 '/opt/letsencrypt-renew.sh'

then expand and restart

expand-template /etc/crontab
service crond restart

The time and day of the month can be chosen at your discretion--I've deliberately chosen a time that isn't at the top or bottom of the hour, or on the first of the month, in the hope of reducing load on letsencrypt's servers. Since the certificates are good for 90 days, this will renew your certificate in plenty of time.

Using Letsencrypt.sh

To be written

Backup

Your certificate, private key, and other important information are stored in /etc/letsencrypt, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., Backup with dar if you're using the workstation backup feature.

Creating certificates for internal servers

You may have one or more internal servers on your network for which you want or need trusted TLS certificates, but which aren't directly accessible from the outside. The Letsencrypt service can handle this too, although the process isn't quite as simple as shown above.

Assumptions:

• You've followed the instructions above to install the Letsencrypt client, and it's working
• The hostname for which you need a certificate resolves, from the outside, to your SME Server. For example, you've registered yourdomain.tld, and a DNS record for *.yourdomain.tld points to your SME Server. You want to create a certificate for privateserver.yourdomain.tld
• Port 80 on your SME Server is open to the Internet--you aren't behind a firewall, or some ISP filtering, that would block it.

You can either create the certificate on your SME Server, and then copy it to the internal server using whatever means that server provides; or (if the internal server is able to run the Letsencrypt client) you can generate the certificate on the internal server.

Generate the certificate on the SME Server

You could simply follow the instructions above, using the FQDN of your internal server. However, those instructions require that you take down your web server briefly. If you were generating a new certificate for the SME Server, you'd need to do this anyway, so that the web server would load the new certificate. If you're generating a certificate for a different internal server, though, you may not want (and you do not need) to take down your SME Server's web server.

Follow the instructions above to create the certificate, but replace the letsencrypt command line with:

./letsencrypt-auto certonly --webroot --webroot-path /home/e-smith/files/primary/html \
 --email admin@yourdomain.tld -d privateserver.yourdomain.tld

The Letsencrypt client will run and place the certificate files in /etc/letsencrypt/live/privateserver.yourdomain.tld/ on your SME Server. You can then copy them to your internal server and install them using whatever mechanism that server provides. This will not alter the configuration of your SME Server.

Once the certificate files are created, installing them on the internal server can be automated. One possible way to do this is to first ensure that the root user on your SME server has an SSH public key generated, that key does not have a passphrase assigned, and that key is trusted by the root user on your internal server. Then, you can add the following to your renewal script:

/opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot \
 --webroot-path /home/e-smith/files/primary/html --email admin@yourdomain.tld \
 -d privateserver.yourdomain.tld

export CERTDIR="/etc/letsencrypt/live/privateserver.yourdomain.tld"
scp $CERTDIR/cert.pem root@privateserver:/etc/pki/tls/certs/privateserver.yourdomain.tld.crt
scp $CERTDIR/privkey.pem root@privateserver:/etc/pki/tls/private/privateserver.yourdomain.tld.key
scp $CERTDIR/chain.pem root@privateserver:/etc/pki/tls/certs/server-chain.crt
ssh root@privateserver /sbin/service httpd restart

You will, of course, need to modify the paths on the internal server to be consistent with where that server expects the certificate files to be; the paths above are applicable to a CentOS-based server.

Generate the certificate on the internal server

If the internal server is Unix-y and otherwise meets the requirements for the Letsencrypt client, you can run the client on the internal server using manual domain authentication. This will require you to create a small file on your SME Server, which you can delete once the certificate is created.

The letsencrypt command would look like:

./letsencrypt-auto certonly --manual --email admin@yourdomain.tld -d privateserver.yourdomain.tld

When the Letsencrypt client runs, it will show you a challenge like the following, with different random strings:

Make sure your web server displays the following content at
http://privateserver.yourdomain.tld/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc before continuing:

U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc.oYz0Q5G7t8oAAhKBGu6Y9InuE1eP2CRhR-RtUVXvloc

At this point, on your SME Server, you'll need to create that file:

# mkdir -p /home/e-smith/files/primary/html/.well-known/acme-challenge
# echo U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc.oYz0Q5G7t8oAAhKBGu6Y9InuE1eP2CRhR-RtUVXvloc > /home/e-smith/files/primary/html/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc

Then press the Enter key on your internal server. As of this writing (10 Dec 2015), the client has a bug which reports "Self-verify of challenge failed", but it will create the certificates anyway (and it will correctly tell you that they're created). Once the client finishes and tells you the certificates are created, you can delete the nonce from your SME Server:

# rm /home/e-smith/files/primary/html/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc

The certificate files will be in /etc/letsencrypt/live/privateserver.yourdomain.tld/ on your internal server.

Source from info

Source: http://forums.contribs.org/index.php/topic,51961.msg266680.html#msg266680