Letsencrypt

From SME Server
Jump to navigation Jump to search
PythonIcon.png Skill level: Medium
The instructions on this page require a basic knowledge of linux.


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 at no cost, easily, and automatically. 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 on this page of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.

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 "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.

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

Multiple clients are available for the Letsencrypt services. The official "certbot" 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. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of dehydrated, an alternative client implemented as a BASH shell script.

Version

Add-on 10:
Contrib 9:
smeserver-letsencrypt
The latest version of smeserver-letsencrypt is available in the SME repository, click on the version number(s) for more information.



Update 10:
Contrib 9:
dehydrated
The latest version of dehydrated is available in the SME repository, click on the version number(s) for more information.



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, and is able to make outbound connections on ports 80 and 443.
  • Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it.

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.

Preparation

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

Contrib Installation of Dehydrated

John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.

Installation

yum install smeserver-letsencrypt --enablerepo=smecontribs

You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.

Updates

Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:

config setprop letsencrypt ACCEPT_TERMS yes
signal-event console-save

Updating

Few reported issue when upgrading the contribs see Bugzilla:10286 and Bugzilla:10097

A full update can be done as follow :

yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs

It is important to do the usual

signal-event post-upgrade;  signal-event reboot

otherwise

signal-event console-save

failure to do this might leave the contribution not working and your certificates not renewed.

Configuration

There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.

Hosts and domains for the certificate

This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:

  • Are configured on your SME Server (e.g., through the Server Manager), and
  • Are configured to use Let's Encrypt.

For example, your SME Server may contain the following domains and hostnames:

  • domain1.com
www.domain1.com
mail.domain1.com
ftp.domain1.com
  • domain2.com
www.domain2.com
mail.domain2.com

For each DOMAIN that you want to be included in the certificate, run this command:

db domains setprop $DOMAIN letsencryptSSLcert enabled

Using the above example, one invocation of the command would look like this:

db domains setprop domain1.com  letsencryptSSLcert enabled

For each HOSTNAME that you want to be included in the certificate, run this command:

db hosts setprop $HOSTNAME letsencryptSSLcert enabled

Using the above example, one invocation of the command would look like this:

db hosts setprop www.domain1.com letsencryptSSLcert enabled

You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames.

config setprop letsencrypt configure all | domains | hosts

With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate.

Other configuration properties

No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:

config setprop letsencrypt email admin@domain1.com

The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.

You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:

config setprop letsencrypt keysize NUMBER

Accept Let's Encrypt terms

Please first read the condition terms for using Let's Encrypt [[1]]

config setprop letsencrypt ACCEPT_TERMS yes

Enable Test Mode

The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:

config setprop letsencrypt status test
signal-event console-save

You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run

dehydrated -c

If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see Bugzilla:10300.

If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.

Enable Production Mode

Once you've successfully tested your installation, set it to production mode using these commands:

config setprop letsencrypt status enabled
signal-event console-save

Then obtain a new certificate from the Let's Encrypt production server:

dehydrated -c -x

The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.

If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity.

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.

Rush jobs

for the test (adjust the domains and hosts):

config setprop letsencrypt ACCEPT_TERMS yes status test
#foreach of your domains you want SSL do the following
db domains setprop domain1.com letsencryptSSLcert enabled
#foreach of your hosts (subdomains) you want SSL do the following
db hosts setprop www.domain1.com letsencryptSSLcert enabled
signal-event console-save
dehydrated -c

Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.

for the production (adjust your email):

config setprop letsencrypt status enabled email admin@domain1.com
signal-event console-save
dehydrated -c -x

Manual Installation of Dehydrated

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.

Contrib install of Dehydrated

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/local/bin/dehydrated -c

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

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

Requiring SSL

Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:

db accounts setprop {accountname} SSL enabled

or

db accounts setprop Primary SSL enabled

Backup

Your certificate, private key, and other important information are stored in /etc/dehydrated, 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. If using Affa for backup, add

Include=/etc/dehydrated

to the Affa configuration file.

Troubleshooting

Certificate Errors

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

Authorization Errors

The first thing is to check all your domains can resolve

http://my.domain/.well-known/acme-challenge

Check that the following files are correctly generated

/etc/dehydrated/config
/etc/dehydrated/domains.txt

Set letsencrypt back to test and remove any generated keys

db configuration setprop letsencrypt status test
rm /etc/dehydrated/certs/* -rf
rm /etc/dehydrated/accounts/* -rf

Then run letsencrypt again

dehydrated -c

To restore the original certificates:

config delprop modSSL CertificateChainFile
config delprop modSSL crt
config delprop modSSL key
signal-event console-save

Errors

If you see the following:

{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}

https://github.com/lukas2511/letsencrypt.sh/issues/2

See above for removing private keys and regenerating


If you see something like this you may have hit the rate limit:

{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}

https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md

https://letsencrypt.org/docs/rate-limits/

Advanced Topics

Obtaining certificates for other servers

The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.

You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do

mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname

You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:

hostname.domain.tld

Then Ctrl-X to exit, Y to save.

The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.

mkdir -p /etc/e-smith/templates-custom/usr/local/bin/hook-script.sh/
nano -w 05deploy_cert_hostname

As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.

At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:

{
    use strict;
    use warnings;
    use esmith::ConfigDB;

    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");

    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )     || 'disabled';

    if ( $letsencryptStatus ne 'disabled' ) {

    $OUT .=<<'_EOF';
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then
 echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com
 exit 0
fi
_EOF

    }
}

Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:

{
    use strict;
    use warnings;
    use esmith::ConfigDB;

    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");

    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )     || 'disabled';

    if ( $letsencryptStatus ne 'disabled' ) {

    $OUT .=<<'_EOF';
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then
  KEY=$3
  CERT=$4
  CHAIN=$6
  scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt
  scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key
  scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt
  ssh root@pbx "/sbin/service httpd reload"
  echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld
  exit 0
fi
_EOF

    }
}

The following fragment would install the new certificate on a Proxmox VE host:

{
    use strict;
    use warnings;
    use esmith::ConfigDB;

    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");

    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )     || 'disabled';

    if ( $letsencryptStatus ne 'disabled' ) {

    $OUT .=<<'_EOF';
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then
  KEY=$3
  CHAIN=$5
  scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key
  scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem
  ssh root@pve "systemctl restart pveproxy"
  echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld
  exit 0
fi
_EOF

    }
}

Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:

signal-event console-save
dehydrated -c

These certificates will be automatically renewed, just like the main server certificate.

Obtaining certificates for a private SME Server

As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:

  • The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address
  • The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80
  • The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)

This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:

config setprop letsencrypt hookScript enabled
config setprop letsencrypt host external.mydomain.tld
config setprop letsencrypt user root
config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
signal-event console-save

The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/

Bugs

Please raise bugs under the SME-Contribs section in bugzilla and select the smeserver-letsencrypt component or use this link


IDProductVersionStatusSummary (10 tasks)
12325SME Contribs10.0CONFIRMEDrenewal fails after domain deleted from manager.
11796SME ContribsFuturCONFIRMEDIs the dns-01 Challenge Supported or is it in planing?
11442SME Contribs10alphaCONFIRMEDmultiple fragments related to some other bugs
10920SME Contribs10alphaCONFIRMEDmove .well-known/acme-challenge out of the Primary ibay
10836SME Contribs9.2CONFIRMEDforce migration from acme-v1 to acme-v2
10818SME Contribs9.2CONFIRMEDtemplate does not respect domain-deleted
10656SME Contribs9.2CONFIRMEDNo letsencrypt certificate for Internet enable password protected Ibay
10483SME Contribs9.2CONFIRMEDrenewal fails with ibay using password
10462SME ContribsFuturCONFIRMEDNFR: implement per certificate / domain
10280SME Contribs9.2CONFIRMEDadd test for domain and host to disable the one at least defined in publicly available dns

Changelog

Only released version in smecontrib are listed here.

smeserver-letsencrypt Changelog: SME 10 (smeaddons)
2022/07/30 Brian Read 0.5-24.sme
- Re-build and link to latest devtools [SME: 11997]
2022/07/25 Jean-Philippe Pialasse 0.5-23.sme
- add to core backup [SME: 12011]
2022/06/15 Brian Read 0.5-22.sme
- Add action to check if dehydrated.timer is running and stop it if so [SME: 11996]
2022/06/12 Brian Read 0.5-21.sme
- Stop systemd timer runnning as well as cron [SME: 11990]
2022/03/23 Jean-Philippe Pialasse 0.5-19.sme
- use a general Alias for acme path and a proxypass [SME: 10637]