Letsencrypt
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
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. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.
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)"
Installation of Dehydrated letsencrypt contrib
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
If your smeaddons repo has been disabled add --enablerepo=smeaddons
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
If your smeaddons repo has been disabled add --enablerepo=smeaddons
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 obtain a certificate for either of the following: all domains, all hostnames, or all domains AND hostnames. Only set one of the following.
config setprop letsencrypt configure domains
config setprop letsencrypt configure hosts
config setprop letsencrypt configure all
To use individually enabled hosts or domains leave the default none.
config setprop letsencrypt configure none
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. see NOTE before setting this to "all"
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
V2 API
With the latest version of letsencrypt/dehydrated the V2 API is needed to create new certificates, V1 is depreciated for creation of new certificates however is still valid for existing certificates created with it.
The key is called API. It will default to '1' if left unset. Options are '1', '2', 'auto'
For updating current V1 certificates leave as default or set to 1, auto
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes configure=none email=####@#####.### hookScript=disabled status=enabled
# config setprop letsencrypt API 1 # signal-event console-save
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes API=1 configure=none email=####@#####.### hookScript=disabled status=enabled
For creating a new certificate or updating a V2 set to 2
# config setprop letsencrypt API 2 # signal-event console-save
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes API=2 configure=none email=####@#####.### hookScript=disabled status=enabled
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.
Archive old certificates
A new function lets you cleanup old and archive old certificates.
dehydrated --cleanup (-gc)
Rush jobs
for the test (adjust the domains and hosts):
config setprop letsencrypt ACCEPT_TERMS yes status test API 2 #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
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
Also see
https://wiki.contribs.org/Useful_Commands#How_to_simply_recreate_the_certificate_for_SME_Server
rm /home/e-smith/ssl.{crt,key,pem}/* config delprop modSSL CommonName config delprop modSSL crt config delprop modSSL key 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
No registration exists matching provided key
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
rateLimited, Too many currently pending Authorizations
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/
Some challenges complete successfully but some hostnames fail
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate.
Using the command:
config setprop letsencrypt configure all
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and ONE does not resolve, the challenge will fail and the certificate will not generate at all.
To resolve this, issue the following command:
config setprop letsencrypt configure none
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:
db domains setprop domain1.com letsencryptSSLcert enabled
and for each hostname:
db hosts setprop www.domain1.com letsencryptSSLcert enabled
db hosts setprop mail.domain1.com letsencryptSSLcert enabled
until all the public facing hostnames are enabled followed by:
signal-event console-save
Thanks to MSmith for the following forum thread.
https://forums.contribs.org/index.php/topic,53052.0.html
Challenge fails with unauthorized 403 error
If your challenge returns something like the following:
ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:unauthorized", "detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text> "status": 403
and your httpd error_log on your server shows something like this:
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied (13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied (13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied
You need to check the ownership and rights on /home/e-smith/files/ibays/Primary and on /home/e-smith/files/ibays/Primary/html. The contrib creates a hidden working directory at /home/e-smith/files/ibays/Primary/html/.well-known and inside that directory a second directory with the following path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with access denied
use the following to check the rights:
cd /home/e-smith/files/ibays
then
ls -l
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):
total 4 drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary
If this is not what you see, you need to correct it.
THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT
From within /home/e-smith/files/ibays/ issue the following:
chown root:root Primary
If the rights are not correct, issue:
chmod 0755 Primary
Next check the html directory.
cd /home/e-smith/files/ibays/Primary
then
ls -l
on my test server I have the following
[root@backupserver Primary]# ls -l total 12 drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin drwxr-s--- 2 admin shared 4096 Jul 25 2016 files drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html
If this is not what you see,
FIRST READ ABOVE WARNING
then adjust as follows
chown admin:shared html
If the rights are not correct, issue:
chmod 2750 html
rerun
dehydrated -c
and your challenges should complete.
https://forums.contribs.org/index.php/topic,53147.0.html
Advanced Topics
Bugs
Please raise bugs under the SME-Contribs section in bugzilla and select the smeserver-letsencrypt component or use this link
ID | Product | Version | Status | Summary (10 tasks) ⇒ |
---|---|---|---|---|
12325 | SME Contribs | 10.0 | CONFIRMED | renewal fails after domain deleted from manager. |
11796 | SME Contribs | Futur | CONFIRMED | Is the dns-01 Challenge Supported or is it in planing? |
11442 | SME Contribs | 10alpha | CONFIRMED | multiple fragments related to some other bugs |
10920 | SME Contribs | 10alpha | CONFIRMED | move .well-known/acme-challenge out of the Primary ibay |
10836 | SME Contribs | 9.2 | CONFIRMED | force migration from acme-v1 to acme-v2 |
10818 | SME Contribs | 9.2 | CONFIRMED | template does not respect domain-deleted |
10656 | SME Contribs | 9.2 | CONFIRMED | No letsencrypt certificate for Internet enable password protected Ibay |
10483 | SME Contribs | 9.2 | CONFIRMED | renewal fails with ibay using password |
10462 | SME Contribs | Futur | CONFIRMED | NFR: implement per certificate / domain |
10280 | SME Contribs | 9.2 | CONFIRMED | add 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.
- Re-build and link to latest devtools [SME: 11997]
- add to core backup [SME: 12011]
- Add action to check if dehydrated.timer is running and stop it if so [SME: 11996]
- Stop systemd timer runnning as well as cron [SME: 11990]
- use a general Alias for acme path and a proxypass [SME: 10637]