Difference between revisions of "Letsencrypt"
(Undo revision 32617 by RequestedDeletion (talk)) |
m (Reverted edits by Nenonano (talk) to last revision by RequestedDeletion) |
||
| Line 1: | Line 1: | ||
| + | {{WIP box}} | ||
| + | {{Note box|This page is a mix of all kinds of (personal) notes and needs a massive cleanup. It does not reflect a normal official contrib page and is incomplete. Use at your own risk!}} | ||
{{Level|Advanced}} | {{Level|Advanced}} | ||
{{Warning box|This procedure change the default certificates and could significantly compromise your server's security.<br />Thorough understanding of linux system management is required.<br /><br /><b>Proceed at your own risk</b>}} | {{Warning box|This procedure change the default certificates and could significantly compromise your server's security.<br />Thorough understanding of linux system management is required.<br /><br /><b>Proceed at your own risk</b>}} | ||
Revision as of 23:18, 13 February 2017
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. 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 "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.
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.
- 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.
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, 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. 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.
Contrib install of Dehydrated
Dehydrated 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.
The script has now been imported into the contribs repository and can be installed as follows:
yum --enablerepo=smecontribs install dehydrated
By itself the script will do absolutely nothing and requires configuration files to be created and the script called either manually or via cron.
Git install of latest version
If you need the latest version of the script then you can remove the contrib above and 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 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 domain-modify /sbin/e-smith/signal-event email-update /sbin/e-smith/signal-event ibay-modify fi
If you have at least version 5.6.0-26 of e-smith-base installed (i.e., if you've installed updates since late January of 2016), replace the three signal-event lines with
/sbin/e-smith/signal-event ssl-update
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.
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.
Production Mode
So remove the test certificate with
rm -rf /etc/dehydrated/certs/
Comment out again the CA line on file /etc/dehydrated/config so it appears like:
# CA="https://acme-staging.api.letsencrypt.org/directory"
and re-run the script
dehydrated -c
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 Dehydrated the certificates must be renewed every 3 months. The process will differ depending on whether you're using the official client or Dehydrated.
Using Dehydrated
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
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.
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.
Install with John Crisp contrib
Sources: https://github.com/reetp/smeserver-letsencrypt
First add his repo
db yum_repositories set reetp repository \ BaseURL https://reetspetit.com/smeserver/\$releasever \ EnableGroups no GPGCheck no \ Name "Mirror John Crisp reetspetit.com" \ GPGKey https://reetspetit.com/RPM-GPG-KEY \ Visible yes status disabled
Then apply changes
signal-event yum-modify
Then install
yum install smeserver-letsencrypt --enablerepo=reetp
Set email
config setprop letsencrypt email my@email.com
TEST FIRST
db configuration setprop letsencrypt status test
ENABLE SOME HOSTS Or DOMAINS for testing purposes
db hosts setprop www.mydomain.com letsencryptSSLcert enabled db domains setprop mydomain.com letsencryptSSLcert enabled
Then run
signal-event console-save service dnscache restart
Create test certificates (file is in the path so should be OK)
dehydrated -c -x
Once you are satisfied with your test
config setprop letsencrypt status enabled signal-event console-save
and
rm /etc/dehydrated/certs/* -rf rm /etc/dehydrated/accounts/* -rf dehydrated -c -x
Note thereafter you ONLY need to run
dehydrated -c
What is next ?
If you make any db key changes run console-save to regenerate your config files
You can now set any public ibays to SSL only using the server manager, or set the following key
db accounts setprop {accountname} SSL enabled
You cannot set the Primary ibay to SSL from the panel
db accounts setprop Primary SSL enabled
signal-event console-save service dnscache restart
or
signal-event ibay-modify Primary
Other info
Optional keys - (not required)
config setprop letsencrypt email (defaults to empty) config setprop letsencrypt keysize (defaults to 4096)
If the licence changes before this script is updated you can specify a new licence URL
config setprop letsencrypt licence https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf
You can enable just a domain or just a host on a domain
Per domain
db domains setprop mydomain.com letsencryptSSLcert enabled
Per host
db hosts setprop www.mydomain.com letsencryptSSLcert enabled
If you want a hook script to push changes remotely (not required)
db configuration setprop letsencrypt hookScript enabled db configuration setprop letsencrypt user someuser db configuration setprop letsencrypt host 1.2.3.4 db configuration setprop letsencrypt path //some/remote/local/path
You can now use a db entry to set all domains or hosts regardless of status
config setprop letsencrypt configure none| all | domains | hosts
default is none
If you set to domains it will enable ALL domains regardless of individual settings. Hosts will be per host as normal If you set to hosts it will enable ALL hosts regardless of individual settings. Domains will be per domain as normal If you set to all it will enable ALL hosts AND domains regardless of individual settings.
Problems
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 -x
To restore the original certificates:
config delprop modSSL CertificateChainFile config delprop modSSL crt config delprop modSSL key
signal-event console-save
Affa
If you have a Letsencrypt certificate on the server you are backing up, then you should also include
Include=/etc/dehydrated
in Affa config file.
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/
Upgrade to the dehydrated script
The old letsencrypt.sh script has been renamed to dehydrated
To upgrade please do the following:
yum --enablerepo=reetp install smeserver-letsencrypt
signal-event post-upgrade; signal-event reboot
alternatively, this should do the same if you do not want to reboot:
signal-event console-save
if you want to keep the same registration
cp -r /etc/letsencrypt.sh/accounts /etc/dehydrated/ cp -r /etc/letsencrypt.sh/certs /etc/dehydrated/
After the reboot you can then run the following to make new certificates:
dehydrated -c -x
I have sometime found that I get connection errors after installation as follows.
If you receive the following error:
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
cd ~ curl https://acme-v01.api.letsencrypt.org/directory dehydrated -c -x
If you then get an error like this:
ERROR: Problem connecting to server (get for http://cert.int-x3.letsencrypt.org/; curl returned with 6)
cd ~ curl http://cert.int-x3.letsencrypt.org/ > /dev/null dehydrated -c -x
Check that the new certificates have been added to the modSSL key:
config show modSSL
modSSL=service CertificateChainFile=/etc/dehydrated/certs/yourdomain.com/chain.pem TCPPort=443 access=public crt=/etc/dehydrated/certs/yourdomain.com/cert.pem key=/etc/dehydrated/certs/yourdomain.com/privkey.pem status=enabled
Source from info
Source: http://forums.contribs.org/index.php/topic,51961.msg266680.html#msg266680
