Difference between revisions of "Letsencrypt"

From SME Server
Jump to navigationJump to search
m (→‎Introduction: Add link to le.org forums for rate limiting)
Line 92: Line 92:
 
  nano /etc/e-smith/templates-custom/etc/crontab/sslrenew
 
  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 (Feb, Apr, Jun, etc.):
+
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 /opt/letsencrypt-renew.sh
 
  48 22 3 */2 * root /opt/letsencrypt-renew.sh

Revision as of 21:14, 11 December 2015

Warning.png 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.


PythonIcon.png 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.png 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.

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.

Installation

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, 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


Important.png 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.


Troubleshooting

In case of errors the apache service may not start anymore, a simple rollback may be used with :

config delprop modSSL crt
config delprop modSSL key
config delprop modSSL CertificateChainFile 
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.

The following script will automatically renew your certificate. Save it in a convenient place, for example, /opt/letsencrypt-renew.sh;don't forget to chmod +x the file

#!/bin/bash
source /opt/rh/python27/enable
export X_SCLS="`scl enable python27 'echo $X_SCLS'`"
/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


Important.png Note:
The above commands enable Python 2.7, but do not disable it again. In general we need to examine the effect of using SCL Python 2.7 on production servers where the default Python version is being used.


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 /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.

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.

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