Difference between revisions of "Letsencrypt"
| Line 200: | Line 200: | ||
/sbin/e-smith/signal-event email-update | /sbin/e-smith/signal-event email-update | ||
/sbin/e-smith/signal-event ibay-modify | /sbin/e-smith/signal-event ibay-modify | ||
| + | /sbin/service httpd-e-smith start | ||
Call this script by running | Call this script by running | ||
Revision as of 17:01, 14 March 2016
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.
At this time (January 2016), a contrib is under active development using the letsencrypt.sh script. See Bug 8276 and the GitHub page for further information.
Users running Windows XP and using either Internet Explorer or Google Chrome will experience certificate errors when visiting web sites with LetsEncrypt certificates. Firefox on Windows XP does not have this problem. This results from a broken SSL implementation in Windows XP. If you need error-free SSL/TLS communications with users using Windows XP, you may need to use a different certificate authority.
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 service httpd-e-smith start
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 = "deploy_cert" ]; then
KEY=$3
CERT=$4
CHAIN=${5/fullchain.pem/chain.pem}
/sbin/e-smith/db configuration setprop modSSL key $KEY
/sbin/e-smith/db configuration setprop modSSL crt $CERT
/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. The process will differ depending on whether you're using the official client or letsencrypt.sh.
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 /sbin/service httpd-e-smith start
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
When run, the Letsencrypt.sh script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config.sh to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run letsencrypt.sh daily:
nano -w /etc/cron.daily/call-letsencrypt.sh
Enter the following in this file:
#!/bin/bash /usr/local/bin/letsencrypt.sh -c
Ctrl-X to exit, Y to save. Then make it executable:
chmod +x /etc/cron.daily/call-letsencrypt.sh
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/ibays/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/ibays/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/ibays/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
