3,250
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + + + + + + + + + + + + + + + + + + + + Line 5:
Line 27: + + Line 10:
Line 34: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→Manual Installation of Dehydrated: new section
==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)===
[[User:Mmccarn|Mmccarn]] ([[User talk: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:
<nowiki>#!/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
</nowiki>
Ctrl-X to exit, Y to save.
Verify correct operation after 1 - 2 days by examining /var/log/dehydrated.log
==Filesystem==
==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 [http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/ 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.
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 [http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/ 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.
* /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
* /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==
==Repositories==
* No idea, but we have to wait until the SCL repo is back on-line correctly.
* 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 [[Custom CA Certificate|here]] and [[Certificate Concepts|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 [[Certificate Integration GoDaddy Certificate|GoDaddy]] or [[Certificate Integration Thawte Certificate|Thawte]] or [[Certificate Integration startssl.com Server Certificate|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 box| 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 box| end of the manual installation and configuration of dehydrated without smeserver-letsencrypt contrib}}