Talk:Letsencrypt

Changes

Any significant change or edits by the wiki team require discussion _before_ somebody simply tries to revert.

Renewal (proposed changes to the "renewal" section)

Mmccarn (talk) 15:06, 4 July 2017 (CEST)

When run, the dehydrated 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 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 dehydrated daily:

nano -w /etc/cron.daily/dehydrated

Uncomment the two lines that invoke dehydrated so that the file looks like this:

#!/bin/sh
# Uncomment to enable auto-renewal
/usr/bin/dehydrated -c 2>&1 | awk '{ print strftime(), $0; fflush(); }' >> /var/log/dehydrated.log

# Uncomment this to auto revoke old certs
/usr/bin/dehydrated_revoke 2>&1 | awk '{ print strftime(), $0; fflush(); }' >> /var/log/dehydrated.log

Ctrl-X to exit, Y to save.

Verify correct operation after 1 - 2 days by examining /var/log/dehydrated.log

Filesystem

I think another filesystem location for the letsencrypt client would be more appropriate--it doesn't seem that we should need to create a new root-level directory called /src, just to put the letsencrypt client in. The Linux Filesystem Hierarchy doesn't call for any such directory, and since the standard SME installation doesn't contain a /src directory, it wouldn't be backed up either. Since it's an executable system maintenance script, it probably really belongs in either /usr/sbin or /usr/local/sbin, but retrieving the script using git puts it in a subdirectory, so it still wouldn't be in any user's path.

At least for the time being, I'd propose putting it in /root/letsencrypt. Thoughts?

• /root should never never be a place to store 'compiling stuff', nor any other 3rd party code. Normally /usr/src is being used for source code. I rather see it to be stored in /opt/letsencrypt, so we are able to have control over permissions

• Nothing stops the admin from setting permissions on anything in /root either, but /opt makes sense.

Repositories

Second, the Letsencrypt client documentation states "On RedHat/CentOS 6 you will need to enable the EPEL repository before install." Is this known to be incorrect? That is, has letsencrypt-auto been shown to run properly without having the EPEL repository enabled? If not, this page should include instructions for installing and enabling that repo.

• No idea, but we have to wait until the SCL repo is back on-line correctly.

• Testing indicates that the EPEL repo does not need to be enabled.

Note about certificates

There's a note placed on the page stating, "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." The process of installing outside (i.e., not self-generated and self-signed) SSL/TLS certificates is documented here and here, among other places on the wiki. The config key and properties appear to be well-documented, and nothing on this page is calling for any changes in any system code or configuration. Is there a reason to believe, or even suspect, that a certificate obtained from letsencrypt.con would behave differently than one obtained from GoDaddy or Thawte or startssl.com?

Upgrade to API v2

Upgrade to v2 API

https://bugs.contribs.org/show_bug.cgi?id=10595

There are some updates to the code and switch to the newer API

HostOverride enabled | disabled

Allows hosts other than 'Self'

API 1 | 2 | auto

Which API version to use

Manual Installation of Dehydrated

	Warning:
	the following is not to be executed if you have installed the smeserver-letsencrypt contrib rpm as it is already handled by the contrib

As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.

Install of Dehydrated rpm from smecontrib repository

The dehydrated script has been imported into the contribs repository and can be installed as follows:

yum --enablerepo=smecontribs install dehydrated

The script must be configured as described below.

Git install of latest version

If you need or want the absolute latest version of the script then you can manually install as follows:

Begin by installing git:

yum install git

Then download the Dehydrated client:

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

Manual Configuration of Dehydrated

You'll need to create two configuration files for Dehydrated.

cd /etc/dehydrated
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 config:

nano -w config

It should look like this:

#!/bin/bash
# config
# CA="https://acme-staging.api.letsencrypt.org/directory"
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/usr/local/bin/dehydrated-hook"
# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL="admin@yourdomain.com"

Ctrl-X to exit, Y to save.

For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.

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/dehydrated-hook

Its contents should look like this:

#!/bin/bash

if [ $1 = "deploy_cert" ]; then
  KEY=$3
  CERT=$4
  CHAIN=$6
  /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 ssl-update
fi

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

chmod +x /usr/local/bin/dehydrated-hook

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 dehydrated and get your certificate.

dehydrated -c

The script will run for a moment and should report success. If it does, look in /etc/dehydrated/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.

If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run

dehydrated -c -x

to obtain trusted a trusted certificate.

Renewal

When run, the dehydrated 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 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 dehydrated daily:

nano -w /etc/cron.daily/call-dehydrated

Enter the following in this file:

#!/bin/bash
/usr/bin/dehydrated -c

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

chmod +x /etc/cron.daily/call-dehydrated

	Warning:
	end of the manual installation and configuration of dehydrated without smeserver-letsencrypt contrib