# Certbot
# =======
# Certbot is the software you'll be running on your machine. Let's Encrypt
# is the Certificate Authority service that handles the certificates.
# For me, I don't like the idea of using the Apache plugin. It would be
# modifying my Apache httpd configuration and such and I'm too paranoid for
# that. ...a Certbot developer misses a typo, Apache fails to restart, etc.
# Not good.
#
# There are many different ways of installing/using Certbot. Here we
# use the certbot-auto script, sudo, and the webroot plugin. This way,
# when cron sends the output from certbot-auto via e-mail, if a certificate
# has been updated, you know to manually restart the appropriate daemon,
# or even script something yourself based on that e-mail.
#
# If you want to create a certificate for the sendmail MTA, using it's
# confDOMAIN_NAME (e.g. smtp.example.com), you can do that with
# certbot-auto, but you would have to be able to make that web accessible.
# You could do this for a few FQDNs with no matching web site (imap, smtp,
# lists) by setting up Apache to use a shared empty directory for those,
# with an index.php to redirect anyone that goes there based on the value
# of $_SERVER['SERVER_NAME'], or an index.html with a HTML meta tag refresh,
# or even simpler - "click here for example.com".
#
# If you are not able to set up Apache for your other domains/FQDNs that
# you need certificates for, or don't have enough access to your Apache
# configuration, you may want to check out https://acme.sh/
# That has a DNS mode that may work for you. If your DNS provider is
# yourself, the "nsupdate API" method may be the way to go. A similar
# feature will most likely be added to certbot-auto, but last time I checked,
# it was not available. I have not delved in to the "manual" plugin thus
# far.
# Make sure ~/bin is there to put certbot-auto in there
cd
mkdir -p -m 0700 bin
# Get certbot-auto
wget https://dl.eff.org/certbot-auto -O bin/certbot-auto
chmod 700 bin/certbot-auto
# Verify that it's the real deal
wget -nc https://dl.eff.org/certbot-auto.asc
gpg --keyserver keys.gnupg.net --recv-key \
A2CFB51FA275A7286234E7B24D17C995CD9775F2
gpg --trusted-key 4D17C995CD9775F2 --verify certbot-auto.asc \
bin/certbot-auto && rm certbot-auto.asc
# Become root
su
# Install the Python-bindings for Augeas
# Not particularly needed if using Webroot, but it may refuse to run
# without it, I haven't tested that fact
pip install python-augeas
# Make sure Python's virtualenv is installed
pip install virtualenv
# If you only have su and sudo is not installed, you should be OK,
# from what I've read. You may need to tweak /etc/suauth
# If you normally use su, but sudo is installed, make sudo usable as
# the non-root user that will be running certbot
#
# If you will not be running renew from cron, i.e. only interactively,
# you don't need this.
echo "$(logname) $(hostname) = (root) NOPASSWD:SETENV: \
/home/$(logname)/bin/certbot-auto" > /etc/sudoers.d/certbot
chmod 440 /etc/sudoers.d/certbot
# Under your web root, wherever the files for your web site are:
# /usr/local/apache2/htdocs
# /usr/local/apache2/htdocs/example.com
# /var/www/htdocs
# ...create a ".well-known/acme-challenge" directory that is readable by
# the user/group that runs the web server. Possibly something like
# root:daemon 750. This is only to verify that everything will work when
# you do it for real. Put a text file in there, make sure you can view it
# with your web browser:
# http://example.com/.well-known/acme-challenge/textfile.txt
# If so, you can remove them. They will be created and removed when
# certbot-auto does it's thing. You will see a hit to that location in your
# access_log if all goes well.
## Once your certificate is created, you will need these two lines in your
## Apache configuration. If SSLCertificateFile and SSLCertificateKeyFile
## are already set, comment them out. Some typical locations for the
## configuration are:
# /usr/local/apache2/conf/extra/httpd-ssl.conf
# /etc/httpd/extra/httpd-ssl.conf
## And these are the specific lines you need to add/update so they point to
## the new certificate files:
# SSLCertificateFile "/etc/letsencrypt/live/example.com/fullchain.pem"
# SSLCertificateKeyFile "/etc/letsencrypt/live/example.com/privkey.pem"
## If you are able to set up Apache to listen to smtp.example.com and
## imap.example.com and so on, you can do this for each of them as well.
## For sendmail, here is an example for your sendmail.mc:
# define(`CERT_DIR', `/etc/letsencrypt/live/smtp.example.com')dnl
# define(`confCACERT_PATH', `CERT_DIR')dnl
# define(`confCACERT', `CERT_DIR/chain.pem')dnl
# define(`confSERVER_CERT', `CERT_DIR/cert.pem')dnl
# define(`confSERVER_KEY', `CERT_DIR/privkey.pem')dnl
# define(`confCLIENT_CERT', `CERT_DIR/cert.pem')dnl
# define(`confCLIENT_KEY', `CERT_DIR/privkey.pem')dnl
#
## sendmail will probably complain unless you do this:
# chmod 600 /etc/letsencrypt/live/smtp.example.com/privkey.pem
## ...which you may need to do after running cacert-auto renew from cron
## when it updates/ads/replaces certificates.
#
# If you are not able to set up Apache for your other domains/FQDNs that
# you need certificates for, you may want to check out https://acme.sh/
# That has a DNS mode that may work for you. If your DNS provider is
# yourself, the "nsupdate API" method may be the way to go.
# This feature will most likely be added to certbot, but last time I
# checked, it was not available.
# No need to rotate logs unless you need additional handling.
# Certbot will limit the # of logs that are in /var/log/letsencrypt
# to 1,000. You can alter that # by using --max-log-backups
# Become your non-root user again
exit
# Run certbot-auto to create an SSL certificate for your domain(s) or FQDN
#
# If you do not specify everything required at the commandline, it will
# ask for it interactively (unless you use -n). The first time you use it,
# it will create a Let's Encrypt account, ask if you agree to the TOS, and
# ask for an e-mail address:
# --agree-tos
# -m email@ddr.ess
# If using the webroot plugin, you can specify the webroot path:
# --webroot-path path, -w path
#
# Configuration will go in /etc/letsencrypt Any time you run certbot-auto,
# if not run as root, it will re-run itself with sudo or su if not
# available. If an update is available, it will also update itself (unless
# you use --no-self-upgrade). You can specify -d multiple times if the
# site is available at multiple FQDNs,
# e.g. -d example.com -d www.example.com
#
# For a list of every commandline option specify '--help all'
#
# It would seem that --no-bootstrap is required when using the apache plugin
# in Slackware. I ran it once before I knew that, it failed, then I decided
# on webroot.
#
# Run certbot-auto:
~/bin/certbot-auto certonly -d example.com -d www.example.com \
--webroot -w /path/to/web/site
# Once the certificate files exist under /etc/letsencrypt/live/example.com
# and you update your configuration to use them (see SSLCertificateFile
# above), restart Apache however you normally do: apachectl, apache2ctl,
# rc.httpd, whatever you've got. With a certificate change, stop then
# start of Apache is probably best.
# List all certificates
~/bin/certbot-auto certificates
# Once it's created and set up, you only need to run renew and it will
# renew any certificates that need to be renewed. --dry-run will make it
# output what would be done without actually doing it.
~/bin/certbot-auto renew --dry-run
# Create a cron job (for your non-root user) to run renew
#
# The short version is that you probably want to run something like:
# sudo $HOME/bin/certbot-auto renew -n --no-self-upgrade
#
# You can put it all in the crontab directly, or create a shell script to
# do everything that you need to be done. An example is here:
# certbot-auto-renew.sh
#
# Run 'crontab -e' to edit the current user's crontab
# In there, set to run twice per day, and specify a random minute (not 0)
# This example will run it at 2:37am and 7:37pm every day
# If you use my example script below, it will also sleep for a random
# number of seconds up to an hour before running certbot-auto
# 37 2,19 * * * $HOME/bin/certbot-auto-renew.sh
#
# If there is any output, the e-mail from cron will be delivered to the
# local user, unless you set MAILTO= in the crontab (see 'man cron'). If
# you do not normally get mail via /var/spool/mail/user, you can also set
# an alias from the local user to somewhere else to have it go where you
# need it to go.
# If you use --no-self-upgrade in cron, to upgrade it, run
# "~/bin/certbot-auto --help" manually every now and then and if an
# upgrade is available, it will replace itself. You can watch the Git
# repository to follow development.
# If you ever had to remove Certbot, after handling your certificates
# and Apache configuration and such, this would zap everything:
test -d /etc/letsencrypt && rm -r /etc/letsencrypt
test -d /opt/eff.org/certbot && rm -r /opt/eff.org/certbot
rmdir --ignore-fail-on-non-empty /opt/eff.org
test -d /var/lib/letsencrypt && rm -r /var/lib/letsencrypt
test -d /var/log/letsencrypt && rm -r /var/log/letsencrypt
rm -f /etc/sudoers.d/certbot ~/bin/certbot-auto