certbot.txt

# it runs as a service, grab the current status from systemctl
$ systemctl | grep cert
# maybe this only shows a certbot.timer, which then fires up the service (or something) when needed.

# then when you see it's failed, you can do a dry-run to see what's up
$ certbot renew --dry-run

# or check the logs in \e[38;5;226m/var/log/letsencrypt/letsencrypt.log\e[0m and \e[38;5;226m/var/log/le-renew.log\e[0m

# Register a new certbot/site/thing/whatever
$ certbot register \e[36m# accept terms, enter email address and politely decline the EFF emails\e[0m

# To add a new cert where you don't have the apache plugin:
$ certbot certonly --webroot -w /var/www/mysite/ -d mysite.nl [-d www.mysite.nl]

# with apache plugin it follows Includes in the httpd conf and figures out the location of the webroot of your vhost:
$ certbot --apache -d mysite.nl

# To simply manually renew a cert [for a specific domain]:
$ certbot renew [--cert-name domain.com]

# certbot does not alwayss automagically restart the webserver after a renew without additional plugins, but you can
# also add a \e[38;5;208mrenew_hook = <executable script path>\e[0m line to \e[38;5;226m/etc/letsencrypt/renewal/<domain.tld>.conf\e[0m
# That script would then restart the server.
# ORRR you can place an executable script in \e[38;5;226m/etc/letsencrypt/renewal-hooks/deploy/\e[0m that does the thing.


\e[36;1m=== .well-known/acme-challenge ===\e[0m

# Make sure the .well-known path can be read o.o Blocking all requests that start with '.' will need an exception
# rule for '.well-known'. Sample nginx config:

# Allow access to the .well-known directory
location ^~ /.well-known {
  allow all;
}

# deny .htaccess, .git etc
location ~ /\. {
  deny all;
}

# ^~ = starts with, ~ = regex (hence why the period in .well-known shouldn't be escaped)