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?