Adding upstream version 0.7.1.upstream/0.7.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

15 files changed, 1066 insertions, 0 deletions

diff --git a/docs/acme-v1.md b/docs/acme-v1.md
new file mode 100644
index 0000000..c0f38c8
--- /dev/null
+++ b/docs/acme-v1.md
@@ -0,0 +1,19 @@
+## (Future) Removal of API version 1
+
+The ACME API version 1 was never really standardized and was only supported by Let's Encrypt. Even though the protocol specification was public,
+it wasn't really friendly to be integrated into existing CA systems so initial adoption was basically non-existant.
+
+ACME version 2 is being designed to overcome these issues by becoming an official IETF standard and supporting a more traditional approach of account
+and order management in the backend, making it friendlier to integrate into existing systems centered around those. It has since become a semi-stable IETF
+standard draft which only ever got two breaking changes, Content-Type enforcement and `POST-as-GET`, the latter being announced in October 2018 to be enforced
+by November 2019. See https://datatracker.ietf.org/wg/acme/documents/ for a better insight into the draft and its changes.
+
+Next to backend changes that many users won't really care about ACME v2 has all of the features ACME v1 had, but also some additional new features like
+e.g. support for [wildcard certificates](domains_txt.md#wildcards).
+
+Since ACME v2 is basically to be considered stable and ACME v1 has no real benefits over v2, there doesn't seem to be much of a reason to keep the old
+protocol around, but since there actually are a few Certificate Authorities and resellers that implemented the v1 protocol and didn't yet make the change
+to v2, so dehydrated still supports the old protocol for now.
+
+Please keep in mind that support for the old ACME protocol version 1 might get removed at any point of bigger inconvenience, e.g. on code changes that
+would require a lot of work or ugly workarounds to keep both versions supported.
diff --git a/docs/dns-verification.md b/docs/dns-verification.md
new file mode 100644
index 0000000..3b6ddb9
--- /dev/null
+++ b/docs/dns-verification.md
@@ -0,0 +1,31 @@
+### dns-01 challenge
+
+This script also supports the new `dns-01`-type verification. This type of verification requires you to be able to create a specific `TXT` DNS record for each hostname included in the certificate.
+
+You need a hook script that deploys the challenge to your DNS server.
+
+The hook script (indicated in the config file or the `--hook/-k` command line argument) gets four arguments:
+
+$1 an operation name (`clean_challenge`, `deploy_challenge`, `deploy_cert`, `invalid_challenge` or `request_failure`) and some operands for that.
+For `deploy_challenge` 
+
+$2 is the domain name for which the certificate is required, 
+
+$3 is a "challenge token" (which is not needed for dns-01), and 
+
+$4 is a token which needs to be inserted in a TXT record for the domain.
+
+Typically, you will need to split the subdomain name in two, the subdomain name and the domain name separately. For example, for "my.example.com", you'll need "my" and "example.com" separately. You then have to prefix "_acme-challenge." before the subdomain name, as in "_acme-challenge.my" and set a TXT record for that on the domain (e.g. "example.com") which has the value supplied in $4
+
+```
+_acme-challenge    IN    TXT    $4
+_acme-challenge.my IN    TXT    $4
+```
+
+That could be done manually (as most providers don't have a DNS API), by having your hook script echo $1, $2 and $4 and then wait (`read -s -r -e < /dev/tty`) - give it a little time to get into their DNS system. Usually providers give you a boxes to put "_acme-challenge.my" and the token value in, and a dropdown to choose the record type, TXT. 
+
+Or when you do have a DNS API, pass the details accordingly to achieve the same thing.
+
+You can delete the TXT record when called with operation `clean_challenge`, when $2 is also the domain name.
+
+Here are some examples: [Examples for DNS-01 hooks](https://github.com/dehydrated-io/dehydrated/wiki)
diff --git a/docs/domains_txt.md b/docs/domains_txt.md
new file mode 100644
index 0000000..dcdbe41
--- /dev/null
+++ b/docs/domains_txt.md
@@ -0,0 +1,107 @@
+## domains.txt
+
+dehydrated uses the file `domains.txt` as configuration for which certificates
+should be requested.
+
+The file should have the following format:
+
+```text
+example.org
+example.com www.example.com
+example.net www.example.net wiki.example.net
+```
+
+This states that there are the following certificates:
+  * `example.org` without any *alternative names*
+  * `example.com` with an *alternative name* of `www.example.com`
+  * `example.net` with the *alternative names*: `www.example.net` and
+    `wiki.example.net`
+
+### Aliases
+
+You can define an *alias* for your certificate which will (instead of the
+primary domain) be used as the directory name under your `CERTDIR` and for a
+per-certificate lookup. This is done using the `>` character.  This allows
+multiple certificates with identical sets of domains but different
+configuration to exist.
+
+Here is an example of using an *alias* called `certalias` for creating the
+certificate for `example.net` with *alternative names* `www.example.net` and
+`wiki.example.net`. The certificate will be stored in the directory `certalias`
+under your `CERTDIR`.
+
+```text
+example.net www.example.net wiki.example.net > certalias
+```
+
+This allows to set per certificates options. The options you can change are
+explained in [Per Certificate Config](per-certificate-config.md).
+
+If you want to create different certificate types for the same domain
+you can use:
+
+```text
+*.service.example.org service.example.org  > star_service_example_org_rsa
+*.service.example.org service.example.org  > star_service_example_org_ecdsa
+```
+
+Then add a config file `certs/star_service_example_org_rsa/config` with
+the value
+
+```
+KEY_ALGO="rsa"
+```
+
+or respectively
+
+```
+KEY_ALGO="ecdsa"
+```
+
+### Wildcards
+
+Support for wildcards was added by the ACME v2 protocol.
+
+Certificates with a wildcard domain as the first (or only) name require an
+*alias* to be set.  *Aliases* can't start with `*.`.
+
+For example to create the wildcard for `*.service.example.com` your
+`domains.txt` could use the *alias* method like this:
+
+```text
+*.service.example.com > star_service_example_com
+```
+
+This creates a wildcard certificate for only `*.service.example.com` and will
+store it in the directory `star_service_example_com` under your `CERTDIR`. As a
+note this certificate will **NOT** be valid for `service.example.com` but only
+for `*.service.example.com`. So it would, for example, be valid for
+`foo.service.example.com`.
+
+
+Another way to create it is using *alternative names*. For example your
+`domains.txt` could do this:
+
+```text
+service.example.com *.service.example.com
+eggs.example.com *.ham.example.com
+```
+
+This creates two certificates one for `service.example.com` with an
+*alternative name* of `*.service.example.com` and a second certificate for
+`eggs.example.com` with an *alternative name* of `*.ham.example.com`.
+
+**Note:** The first certificate is valid for both `service.example.com` and for
+`*.service.example.com` which can be a useful way to create wildcard
+certificates.
+
+### Drop-in directory
+
+If a directory named `domains.txt.d` exists in the same location as
+`domains.txt`, the contents of `*.txt` files in that directory are appended to
+the list of domains, in alphabetical order of the filenames. This is useful for
+automation, as it doesn't require editing an existing file to add new domains.
+
+Warning: Behaviour of this might change as the naming between `domains.txt.d`
+and the `DOMAINS_D` config variable (which is used for per-certificate
+configuration) is a bit confusing.
diff --git a/docs/ecc.md b/docs/ecc.md
new file mode 100644
index 0000000..87d52ba
--- /dev/null
+++ b/docs/ecc.md
@@ -0,0 +1,4 @@
+### Elliptic Curve Cryptography (ECC)
+
+This script also supports certificates with Elliptic Curve public keys!
+Simply set the `KEY_ALGO` variable in one of the config files.
diff --git a/docs/examples/config b/docs/examples/config
new file mode 100644
index 0000000..51e38de
--- /dev/null
+++ b/docs/examples/config
@@ -0,0 +1,132 @@
+########################################################
+# This is the main config file for dehydrated          #
+#                                                      #
+# This file is looked for in the following locations:  #
+# $SCRIPTDIR/config (next to this script)              #
+# /usr/local/etc/dehydrated/config                     #
+# /etc/dehydrated/config                               #
+# ${PWD}/config (in current working-directory)         #
+#                                                      #
+# Default values of this config are in comments        #
+########################################################
+
+# Which user should dehydrated run as? This will be implicitly enforced when running as root
+#DEHYDRATED_USER=
+
+# Which group should dehydrated run as? This will be implicitly enforced when running as root
+#DEHYDRATED_GROUP=
+
+# Resolve names to addresses of IP version only. (curl)
+# supported values: 4, 6
+# default: <unset>
+#IP_VERSION=
+
+# URL to certificate authority or internal preset
+# Presets: letsencrypt, letsencrypt-test, zerossl, buypass, buypass-test
+# default: letsencrypt
+#CA="letsencrypt"
+
+# Path to old certificate authority
+# Set this value to your old CA value when upgrading from ACMEv1 to ACMEv2 under a different endpoint.
+# If dehydrated detects an account-key for the old CA it will automatically reuse that key
+# instead of registering a new one.
+# default: https://acme-v01.api.letsencrypt.org/directory
+#OLDCA="https://acme-v01.api.letsencrypt.org/directory"
+
+# Which challenge should be used? Currently http-01, dns-01 and tls-alpn-01 are supported
+#CHALLENGETYPE="http-01"
+
+# Path to a directory containing additional config files, allowing to override
+# the defaults found in the main configuration file. Additional config files
+# in this directory needs to be named with a '.sh' ending.
+# default: <unset>
+#CONFIG_D=
+
+# Directory for per-domain configuration files.
+# If not set, per-domain configurations are sourced from each certificates output directory.
+# default: <unset>
+#DOMAINS_D=
+
+# Base directory for account key, generated certificates and list of domains (default: $SCRIPTDIR -- uses config directory if undefined)
+#BASEDIR=$SCRIPTDIR
+
+# File containing the list of domains to request certificates for (default: $BASEDIR/domains.txt)
+#DOMAINS_TXT="${BASEDIR}/domains.txt"
+
+# Output directory for generated certificates
+#CERTDIR="${BASEDIR}/certs"
+
+# Output directory for alpn verification certificates
+#ALPNCERTDIR="${BASEDIR}/alpn-certs"
+
+# Directory for account keys and registration information
+#ACCOUNTDIR="${BASEDIR}/accounts"
+
+# Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /var/www/dehydrated)
+#WELLKNOWN="/var/www/dehydrated"
+
+# Default keysize for private keys (default: 4096)
+#KEYSIZE="4096"
+
+# Path to openssl config file (default: <unset> - tries to figure out system default)
+#OPENSSL_CNF=
+
+# Path to OpenSSL binary (default: "openssl")
+#OPENSSL="openssl"
+
+# Extra options passed to the curl binary (default: <unset>)
+#CURL_OPTS=
+
+# Program or function called in certain situations
+#
+# After generating the challenge-response, or after failed challenge (in this case altname is empty)
+# Given arguments: clean_challenge|deploy_challenge altname token-filename token-content
+#
+# After successfully signing certificate
+# Given arguments: deploy_cert domain path/to/privkey.pem path/to/cert.pem path/to/fullchain.pem
+#
+# BASEDIR and WELLKNOWN variables are exported and can be used in an external program
+# default: <unset>
+#HOOK=
+
+# Chain clean_challenge|deploy_challenge arguments together into one hook call per certificate (default: no)
+#HOOK_CHAIN="no"
+
+# Minimum days before expiration to automatically renew certificate (default: 30)
+#RENEW_DAYS="30"
+
+# Regenerate private keys instead of just signing new certificates on renewal (default: yes)
+#PRIVATE_KEY_RENEW="yes"
+
+# Create an extra private key for rollover (default: no)
+#PRIVATE_KEY_ROLLOVER="no"
+
+# Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1
+#KEY_ALGO=secp384r1
+
+# E-mail to use during the registration (default: <unset>)
+#CONTACT_EMAIL=
+
+# Lockfile location, to prevent concurrent access (default: $BASEDIR/lock)
+#LOCKFILE="${BASEDIR}/lock"
+
+# Option to add CSR-flag indicating OCSP stapling to be mandatory (default: no)
+#OCSP_MUST_STAPLE="no"
+
+# Fetch OCSP responses (default: no)
+#OCSP_FETCH="no"
+
+# OCSP refresh interval (default: 5 days)
+#OCSP_DAYS=5
+
+# Issuer chain cache directory (default: $BASEDIR/chains)
+#CHAINCACHE="${BASEDIR}/chains"
+
+# Automatic cleanup (default: no)
+#AUTO_CLEANUP="no"
+
+# ACME API version (default: auto)
+#API=auto
+
+# Preferred issuer chain (default: <unset> -> uses default chain)
+#PREFERRED_CHAIN=
diff --git a/docs/examples/domains.txt b/docs/examples/domains.txt
new file mode 100644
index 0000000..2079346
--- /dev/null
+++ b/docs/examples/domains.txt
@@ -0,0 +1,39 @@
+# Create certificate for 'example.org' with an alternative name of
+# 'www.example.org'. It will be stored in the directory ${CERT_DIR}/example.org
+example.org www.example.org
+
+# Create certificate for 'example.com' with alternative names of
+# 'www.example.com' & 'wiki.example.com'. It will be stored in the directory
+# ${CERT_DIR}/example.com
+example.com www.example.com wiki.example.com
+
+# Using the alias 'certalias' create certificate for 'example.net' with
+# alternate name 'www.example.net' and store it in the directory
+# ${CERTDIR}/certalias
+example.net www.example.net > certalias
+
+# Using the alias 'service_example_com' create a wildcard certificate for
+# '*.service.example.com' and store it in the directory
+# ${CERTDIR}/service_example_com
+# NOTE: It is NOT a certificate for 'service.example.com'
+*.service.example.com > service_example_com
+
+# Using the alias 'star_service_example_org' create a wildcard certificate for
+# '*.service.example.org' with an alternative name of `service.example.org'
+# and store it in the directory ${CERTDIR}/star_service_example_org
+# NOTE: It is a certificate for 'service.example.org'
+*.service.example.org service.example.org  > star_service_example_org
+
+# Optionally you can also append the certificate algorithm here to create
+# multiple certificate types for the same domain.
+#
+# This allows to set per certificates options. How to do this is
+# explained in [domains.txt documentation](domains_txt.md).
+#
+*.service.example.org service.example.org  > star_service_example_org_rsa
+*.service.example.org service.example.org  > star_service_example_org_ecdsa
+
+# Create a certificate for 'service.example.net' with an alternative name of
+# '*.service.example.net' (which is a wildcard domain) and store it in the
+# directory ${CERTDIR}/service.example.net
+service.example.net *.service.example.net
diff --git a/docs/examples/hook.sh b/docs/examples/hook.sh
new file mode 100755
index 0000000..4fc9015
--- /dev/null
+++ b/docs/examples/hook.sh
@@ -0,0 +1,220 @@
+#!/usr/bin/env bash
+
+deploy_challenge() {
+  local DOMAIN="${1}" TOKEN_FILENAME="${2}" TOKEN_VALUE="${3}"
+
+  # This hook is called once for every domain that needs to be
+  # validated, including any alternative names you may have listed.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The domain name (CN or subject alternative name) being
+  #   validated.
+  # - TOKEN_FILENAME
+  #   The name of the file containing the token to be served for HTTP
+  #   validation. Should be served by your web server as
+  #   /.well-known/acme-challenge/${TOKEN_FILENAME}.
+  # - TOKEN_VALUE
+  #   The token value that needs to be served for validation. For DNS
+  #   validation, this is what you want to put in the _acme-challenge
+  #   TXT record. For HTTP validation it is the value that is expected
+  #   be found in the $TOKEN_FILENAME file.
+
+  # Simple example: Use nsupdate with local named
+  # printf 'server 127.0.0.1\nupdate add _acme-challenge.%s 300 IN TXT "%s"\nsend\n' "${DOMAIN}" "${TOKEN_VALUE}" | nsupdate -k /var/run/named/session.key
+}
+
+clean_challenge() {
+  local DOMAIN="${1}" TOKEN_FILENAME="${2}" TOKEN_VALUE="${3}"
+
+  # This hook is called after attempting to validate each domain,
+  # whether or not validation was successful. Here you can delete
+  # files or DNS records that are no longer needed.
+  #
+  # The parameters are the same as for deploy_challenge.
+
+  # Simple example: Use nsupdate with local named
+  # printf 'server 127.0.0.1\nupdate delete _acme-challenge.%s TXT "%s"\nsend\n' "${DOMAIN}" "${TOKEN_VALUE}" | nsupdate -k /var/run/named/session.key
+}
+
+sync_cert() {
+  local KEYFILE="${1}" CERTFILE="${2}" FULLCHAINFILE="${3}" CHAINFILE="${4}" REQUESTFILE="${5}"
+
+  # This hook is called after the certificates have been created but before
+  # they are symlinked. This allows you to sync the files to disk to prevent
+  # creating a symlink to empty files on unexpected system crashes.
+  #
+  # This hook is not intended to be used for further processing of certificate
+  # files, see deploy_cert for that.
+  #
+  # Parameters:
+  # - KEYFILE
+  #   The path of the file containing the private key.
+  # - CERTFILE
+  #   The path of the file containing the signed certificate.
+  # - FULLCHAINFILE
+  #   The path of the file containing the full certificate chain.
+  # - CHAINFILE
+  #   The path of the file containing the intermediate certificate(s).
+  # - REQUESTFILE
+  #   The path of the file containing the certificate signing request.
+
+  # Simple example: sync the files before symlinking them
+  # sync "${KEYFILE}" "${CERTFILE}" "${FULLCHAINFILE}" "${CHAINFILE}" "${REQUESTFILE}"
+}
+
+deploy_cert() {
+  local DOMAIN="${1}" KEYFILE="${2}" CERTFILE="${3}" FULLCHAINFILE="${4}" CHAINFILE="${5}" TIMESTAMP="${6}"
+
+  # This hook is called once for each certificate that has been
+  # produced. Here you might, for instance, copy your new certificates
+  # to service-specific locations and reload the service.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The primary domain name, i.e. the certificate common
+  #   name (CN).
+  # - KEYFILE
+  #   The path of the file containing the private key.
+  # - CERTFILE
+  #   The path of the file containing the signed certificate.
+  # - FULLCHAINFILE
+  #   The path of the file containing the full certificate chain.
+  # - CHAINFILE
+  #   The path of the file containing the intermediate certificate(s).
+  # - TIMESTAMP
+  #   Timestamp when the specified certificate was created.
+
+  # Simple example: Copy file to nginx config
+  # cp "${KEYFILE}" "${FULLCHAINFILE}" /etc/nginx/ssl/; chown -R nginx: /etc/nginx/ssl
+  # systemctl reload nginx
+}
+
+deploy_ocsp() {
+  local DOMAIN="${1}" OCSPFILE="${2}" TIMESTAMP="${3}"
+
+  # This hook is called once for each updated ocsp stapling file that has
+  # been produced. Here you might, for instance, copy your new ocsp stapling
+  # files to service-specific locations and reload the service.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The primary domain name, i.e. the certificate common
+  #   name (CN).
+  # - OCSPFILE
+  #   The path of the ocsp stapling file
+  # - TIMESTAMP
+  #   Timestamp when the specified ocsp stapling file was created.
+
+  # Simple example: Copy file to nginx config
+  # cp "${OCSPFILE}" /etc/nginx/ssl/; chown -R nginx: /etc/nginx/ssl
+  # systemctl reload nginx
+}
+
+
+unchanged_cert() {
+  local DOMAIN="${1}" KEYFILE="${2}" CERTFILE="${3}" FULLCHAINFILE="${4}" CHAINFILE="${5}"
+
+  # This hook is called once for each certificate that is still
+  # valid and therefore wasn't reissued.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The primary domain name, i.e. the certificate common
+  #   name (CN).
+  # - KEYFILE
+  #   The path of the file containing the private key.
+  # - CERTFILE
+  #   The path of the file containing the signed certificate.
+  # - FULLCHAINFILE
+  #   The path of the file containing the full certificate chain.
+  # - CHAINFILE
+  #   The path of the file containing the intermediate certificate(s).
+}
+
+invalid_challenge() {
+  local DOMAIN="${1}" RESPONSE="${2}"
+
+  # This hook is called if the challenge response has failed, so domain
+  # owners can be aware and act accordingly.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The primary domain name, i.e. the certificate common
+  #   name (CN).
+  # - RESPONSE
+  #   The response that the verification server returned
+
+  # Simple example: Send mail to root
+  # printf "Subject: Validation of ${DOMAIN} failed!\n\nOh noez!" | sendmail root
+}
+
+request_failure() {
+  local STATUSCODE="${1}" REASON="${2}" REQTYPE="${3}" HEADERS="${4}"
+
+  # This hook is called when an HTTP request fails (e.g., when the ACME
+  # server is busy, returns an error, etc). It will be called upon any
+  # response code that does not start with '2'. Useful to alert admins
+  # about problems with requests.
+  #
+  # Parameters:
+  # - STATUSCODE
+  #   The HTML status code that originated the error.
+  # - REASON
+  #   The specified reason for the error.
+  # - REQTYPE
+  #   The kind of request that was made (GET, POST...)
+  # - HEADERS
+  #   HTTP headers returned by the CA
+
+  # Simple example: Send mail to root
+  # printf "Subject: HTTP request failed failed!\n\nA http request failed with status ${STATUSCODE}!" | sendmail root
+}
+
+generate_csr() {
+  local DOMAIN="${1}" CERTDIR="${2}" ALTNAMES="${3}"
+
+  # This hook is called before any certificate signing operation takes place.
+  # It can be used to generate or fetch a certificate signing request with external
+  # tools.
+  # The output should be just the certificate signing request formatted as PEM.
+  #
+  # Parameters:
+  # - DOMAIN
+  #   The primary domain as specified in domains.txt. This does not need to
+  #   match with the domains in the CSR, it's basically just the directory name.
+  # - CERTDIR
+  #   Certificate output directory for this particular certificate. Can be used
+  #   for storing additional files.
+  # - ALTNAMES
+  #   All domain names for the current certificate as specified in domains.txt.
+  #   Again, this doesn't need to match with the CSR, it's just there for convenience.
+
+  # Simple example: Look for pre-generated CSRs
+  # if [ -e "${CERTDIR}/pre-generated.csr" ]; then
+  #   cat "${CERTDIR}/pre-generated.csr"
+  # fi
+}
+
+startup_hook() {
+  # This hook is called before the cron command to do some initial tasks
+  # (e.g. starting a webserver).
+
+  :
+}
+
+exit_hook() {
+  local ERROR="${1:-}"
+
+  # This hook is called at the end of the cron command and can be used to
+  # do some final (cleanup or other) tasks.
+  #
+  # Parameters:
+  # - ERROR
+  #   Contains error message if dehydrated exits with error
+}
+
+HANDLER="$1"; shift
+if [[ "${HANDLER}" =~ ^(deploy_challenge|clean_challenge|sync_cert|deploy_cert|deploy_ocsp|unchanged_cert|invalid_challenge|request_failure|generate_csr|startup_hook|exit_hook)$ ]]; then
+  "$HANDLER" "$@"
+fi
diff --git a/docs/hook_chain.md b/docs/hook_chain.md
new file mode 100644
index 0000000..a4f7a5b
--- /dev/null
+++ b/docs/hook_chain.md
@@ -0,0 +1,62 @@
+# HOOK_CHAIN
+
+If you want to deploy (and clean) all challenges for a single certificate in one hook call you can use `HOOK_CHAIN=yes` in your config.
+
+Calls to your hook script change in a way that instead of having only X parameters on deploy_challenge and clean_challenge it will have Y*X parameters,
+where Y is the number of domains in your cert, and you'll have to iterate over a set of X parameters at a time in your hook script.
+
+See below for an example on how the calls change:
+
+### HOOK_CHAIN="no" (default behaviour)
+```
+# INFO: Using main config file /etc/dehydrated/config
+Processing lukas.im with alternative names: www.lukas.im
+ + Checking domain name(s) of existing cert... unchanged.
+ + Checking expire date of existing cert...
+ + Valid till Jul  7 20:54:00 2016 GMT (Longer than 30 days). Ignoring because renew was forced!
+ + Signing domains...
+ + Generating private key...
+ + Generating signing request...
+ + Requesting challenge for lukas.im...
+ + Requesting challenge for www.lukas.im...
+HOOK: deploy_challenge lukas.im blablabla blablabla.supersecure
+ + Responding to challenge for lukas.im...
+HOOK: clean_challenge lukas.im blablabla blablabla.supersecure
+ + Challenge is valid!
+HOOK: deploy_challenge www.lukas.im blublublu blublublu.supersecure
+ + Responding to challenge for www.lukas.im...
+HOOK: clean_challenge www.lukas.im blublublu blublublu.supersecure
+ + Challenge is valid!
+ + Requesting certificate...
+ + Checking certificate...
+ + Done!
+ + Creating fullchain.pem...
+HOOK: deploy_cert lukas.im /etc/dehydrated/certs/lukas.im/privkey.pem /etc/dehydrated/certs/lukas.im/cert.pem /etc/dehydrated/certs/lukas.im/fullchain.pem /etc/dehydrated/certs/lukas.im/chain.pem 1460152442
+ + Done!
+```
+
+### HOOK_CHAIN="yes"
+```
+# INFO: Using main config file /etc/dehydrated/config
+Processing lukas.im with alternative names: www.lukas.im
+ + Checking domain name(s) of existing cert... unchanged.
+ + Checking expire date of existing cert...
+ + Valid till Jul  7 20:52:00 2016 GMT (Longer than 30 days). Ignoring because renew was forced!
+ + Signing domains...
+ + Generating private key...
+ + Generating signing request...
+ + Requesting challenge for lukas.im...
+ + Requesting challenge for www.lukas.im...
+HOOK: deploy_challenge lukas.im blablabla blablabla.supersecure www.lukas.im blublublu blublublu.supersecure
+ + Responding to challenge for lukas.im...
+ + Challenge is valid!
+ + Responding to challenge for www.lukas.im...
+ + Challenge is valid!
+HOOK: clean_challenge lukas.im blablabla blablabla.supersecure www.lukas.im blublublu blublublu.supersecure
+ + Requesting certificate...
+ + Checking certificate...
+ + Done!
+ + Creating fullchain.pem...
+HOOK: deploy_cert lukas.im /etc/dehydrated/certs/lukas.im/privkey.pem /etc/dehydrated/certs/lukas.im/cert.pem /etc/dehydrated/certs/lukas.im/fullchain.pem /etc/dehydrated/certs/lukas.im/chain.pem 1460152408
+ + Done!
+```
diff --git a/docs/logo.png b/docs/logo.png
new file mode 100644
index 0000000..a40bfe8
--- /dev/null
+++ b/docs/logo.png
diff --git a/docs/man/dehydrated.1 b/docs/man/dehydrated.1
new file mode 100644
index 0000000..d866fec
--- /dev/null
+++ b/docs/man/dehydrated.1
@@ -0,0 +1,155 @@
+.TH DEHYDRATED 1 2018-01-13 "Dehydrated ACME Client"
+.SH NAME
+dehydrated \- ACME client implemented as a shell-script
+.SH SYNOPSIS
+.B dehydrated
+[\fBcommand\fR [\fBargument\fR]]
+[\fBargument\fR [\fBargument\fR]]
+.IR ...
+.SH DESCRIPTION
+A client for ACME-based Certificate Authorities, such as LetsEncrypt.  It can
+be used to request and obtain TLS certificates from an ACME-based
+certificate authority.
+
+Before any certificates can be requested, Dehydrated needs
+to acquire an account with the Certificate Authorities. Optionally, an email
+address can be provided.  It will be used to e.g. notify about expiring
+certificates. You will usually need to accept the Terms of Service of the CA.
+Dehydrated will notify if no account is configured. Run with \fB--register
+--accept-terms\fR to create a new account.
+
+Next, all domain names must be provided in domains.txt. The format is line
+based: If the file contains two lines "example.com" and "example.net",
+Dehydrated will request two certificate, one for "example.com" and the other
+for "example.net". A single line while "example.com example.net" will request a
+single certificate valid for both "example.net" and "example.com" through the \fISubject
+Alternative Name\fR (SAN) field.
+
+For the next step, one way of verifying domain name ownership needs to be
+configured.  Dehydrated implements \fIhttp-01\fR and \fIdns-01\fR verification. 
+
+The \fIhttp-01\fR verification provides proof of ownership by providing a
+challenge token. In order to do that, the directory referenced in the
+\fIWELLKNOWN\fR config variable needs to be exposed at
+\fIhttp://{domain}/.well-known/acme-challenge/\fR, where {domain} is every
+domain name specified in \fIdomains.txt\fR.  Dehydrated does not provide its
+own challenge responder, but relies on an existing web server to provide the
+challenge response.  See \fIwellknown.md\fR for configuration examples of
+popular web servers.
+
+The \fIdns-01\fR verification works by providing a challenge token through DNS.
+This is especially interesting for hosts that cannot be exposed to the public
+Internet.  Because adding records to DNS zones is oftentimes highly specific to
+the software or the DNS provider at hand, there are many third party hooks
+available for dehydrated.  See \fIdns-verification.md\fR for hooks for popular
+DNS servers and DNS hosters.
+
+Finally, the certificates need to be requested and updated on a regular basis.
+This can happen through a cron job or a timer. Initially, you may enforce this
+by invoking \fIdehydrated -c\fR manually.
+
+After a successful run, certificates are stored in
+\fI/etc/dehydrated/certs/{domain}\fR, where {domain} is the domain name in the
+first column of \fIdomains.txt\fR.
+
+.SH OPTIONS
+
+.BR Commands
+.TP
+.BR \-\-version ", " \-v
+Print version information
+.TP
+.BR \-\-register
+Register account key
+.TP
+.BR \-\-account
+Update account contact information
+.TP
+.BR \-\-cron ", " \-c
+Sign/renew non\-existent/changed/expiring certificates.
+.TP
+.BR \-\-signcsr ", " \-s " " \fIpath/to/csr.pem\fR
+Sign a given CSR, output CRT on stdout (advanced usage)
+.TP
+.BR \-\-revoke ", " \-r " " \fIpath/to/cert.pem\fR
+Revoke specified certificate
+.TP
+.BR \-\-cleanup ", " \-gc
+Move unused certificate files to archive directory
+.TP
+.BR \-\-help ", " \-h
+Show help text
+.TP
+.BR \-\-env ", " \-e
+Output configuration variables for use in other scripts
+
+.PP
+.BR Parameters
+.TP
+.BR \-\-accept\-terms
+Accept CAs terms of service
+.TP
+.BR \-\-full\-chain ", " \-fc
+Print full chain when using \fB\-\-signcsr\fR
+.TP
+.BR \-\-ipv4 ", " \-4
+Resolve names to IPv4 addresses only
+.TP
+.BR \-\-ipv6 ", " \-6
+Resolve names to IPv6 addresses only
+.TP
+.BR \-\-domain ", " \-d " " \fIdomain.tld\fR
+Use specified domain name(s) instead of domains.txt entry (one certificate!)
+.TP
+.BR \-\-keep\-going ", " \-g
+Keep going after encountering an error while creating/renewing multiple
+certificates in cron mode
+.TP
+.BR \-\-force ", " \-x
+Force renew of certificate even if it is longer valid than value in RENEW_DAYS
+.TP
+.BR \-\-no\-lock ", " \-n
+Don't use lockfile (potentially dangerous!)
+.TP
+.BR \-\-lock\-suffix " " \fIexample.com\fR
+Suffix lockfile name with a string (useful for use with \-d)
+.TP
+.BR \-\-ocsp
+Sets option in CSR indicating OCSP stapling to be mandatory
+.TP
+.BR \-\-privkey ", " \-p " " \fIpath/to/key.pem\fR
+Use specified private key instead of account key (useful for revocation)
+.TP
+.BR \-\-config ", " \-f " " \fIpath/to/config\fR
+Use specified config file
+.TP
+.BR \-\-hook ", " \-k " " \fIpath/to/hook.sh\fR
+Use specified script for hooks
+.TP
+.BR \-\-out ", " \-o " " \fIcerts/directory\fR
+Output certificates into the specified directory
+.TP
+.BR \-\-challenge ", " \-t " " \fI[http\-01|dns\-01]\fR
+Which challenge should be used? Currently http\-01 and dns\-01 are supported
+.TP
+.BR \-\-algo ", " \-a " " \fI[rsa|prime256v1|secp384r1]\fR
+Which public key algorithm should be used? Supported: rsa, prime256v1 and
+secp384r1
+.SH DIAGNOSTICS
+The program exits 0 if everything was fine, 1 if an error occurred.
+.SH BUGS
+Please report any bugs that you may encounter at the project web site
+.UR https://github.com/lukas2511/dehydrated/issues
+.UE .
+.SH AUTHOR
+Dehydrated was written by Lukas Schauer. This man page was contributed by
+Daniel Molkentin.
+.SH COPYRIGHT
+Copyright 2015-2018 by Lukas Schauer and the respective contributors.
+Provided under the MIT License. See the LICENSE file that accompanies the
+distribution for licensing information.
+.SH SEE ALSO
+Full documentation along with configuration examples are provided in the \fIdocs\fR
+directory of the distribution, or at
+.UR https://github.com/lukas2511/dehydrated/tree/master/docs
+.UE .
diff --git a/docs/per-certificate-config.md b/docs/per-certificate-config.md
new file mode 100644
index 0000000..3dd34dc
--- /dev/null
+++ b/docs/per-certificate-config.md
@@ -0,0 +1,29 @@
+# Config on per-certificate base
+
+dehydrated allows a few configuration variables to be set on a per-certificate base.
+
+To use this feature create a `config` file in the certificates output directory (e.g. `certs/example.org/config`).
+
+Currently supported options:
+
+- PRIVATE_KEY_RENEW
+- PRIVATE_KEY_ROLLOVER
+- KEY_ALGO
+- KEYSIZE
+- OCSP_MUST_STAPLE
+- OCSP_FETCH
+- OCSP_DAYS
+- CHALLENGETYPE
+- HOOK
+- HOOK_CHAIN
+- WELLKNOWN
+- OPENSSL_CNF
+- RENEW_DAYS
+- PREFERRED_CHAIN
+
+## DOMAINS_D
+
+If `DOMAINS_D` is set, dehydrated will use it for your per-certificate configurations.
+Instead of `certs/example.org/config` it will look for a configuration under `DOMAINS_D/example.org`.
+
+If an alias is set, it will be used instead of the primary domain name.
diff --git a/docs/staging.md b/docs/staging.md
new file mode 100644
index 0000000..07c675b
--- /dev/null
+++ b/docs/staging.md
@@ -0,0 +1,14 @@
+# Staging
+
+Let’s Encrypt has stringent rate limits in place.
+
+If you start testing using the production endpoint (which is the default),
+you will quickly hit these limits and find yourself locked out.
+
+To avoid this, please set the CA property to the Let’s Encrypt staging server URL in your config file:
+
+```bash
+CA="https://acme-staging-v02.api.letsencrypt.org/directory"
+```
+
+Alternatively you can define the CA using the CLI argument `--ca letsencrypt-test` (`letsencrypt-test` is an integrated preset-CA corresponding to the URL above).
diff --git a/docs/tls-alpn.md b/docs/tls-alpn.md
new file mode 100644
index 0000000..fc19698
--- /dev/null
+++ b/docs/tls-alpn.md
@@ -0,0 +1,124 @@
+# TLS-ALPN-01
+
+With `tls-alpn-01`-type verification Let's Encrypt (or the ACME-protocol in general) is checking if you are in control of a domain by accessing
+your webserver using a custom ALPN and expecting a specially crafted TLS certificate containing a verification token.
+It will do that for any (sub-)domain you want to sign a certificate for.
+
+Dehydrated generates the required verification certificates, but the delivery is out of its scope.
+
+### Example lighttpd config
+
+lighttpd can be configured to recognize ALPN `acme-tls/1` and to respond to such
+requests using the specially crafted TLS certificates generated by dehydrated.
+Configure lighttpd and dehydrated to use the same path for these certificates.
+(Be sure to allow read access to the user account under which the lighttpd
+server is running.) `mkdir -p /etc/dehydrated/alpn-certs`
+
+lighttpd.conf:
+```
+ssl.acme-tls-1 = "/etc/dehydrated/alpn-certs"
+```
+
+When renewing certificates, specify `-t tls-alpn-01` and `--alpn /etc/dehydrated/alpn-certs` to dehydrated, e.g.
+```
+dehydrated -t tls-alpn-01 --alpn /etc/dehydrated/alpn-certs -c --out /etc/lighttpd/certs -d www.example.com
+# gracefully reload lighttpd to use the new certificates by sending lighttpd pid SIGUSR1
+systemctl reload lighttpd
+```
+
+### Example nginx config
+
+On an nginx tcp load-balancer you can use the `ssl_preread` module to map a different port for acme-tls
+requests than for e.g. HTTP/2 or HTTP/1.1 requests.
+
+Your config should look something like this:
+
+```nginx
+stream {
+  map $ssl_preread_alpn_protocols $tls_port {
+    ~\bacme-tls/1\b 10443;
+    default 443;
+  }
+
+  server {
+    listen 443;
+    listen [::]:443;
+    proxy_pass 10.13.37.42:$tls_port;
+    ssl_preread on;
+  }
+}
+```
+
+That way https requests are forwarded to port 443 on the backend server, and acme-tls/1 requests are
+forwarded to port 10443.
+
+In the future nginx might support internal routing based on custom ALPNs, but for now you'll have to
+use a custom responder for the alpn verification certificates (see below).
+
+### Example responder
+
+I hacked together a simple responder in Python, it might not be the best, but it works for me:
+
+```python
+#!/usr/bin/env python3
+
+import ssl
+import socketserver
+import threading
+import re
+import os
+
+ALPNDIR="/etc/dehydrated/alpn-certs"
+PROXY_PROTOCOL=False
+
+FALLBACK_CERTIFICATE="/etc/ssl/certs/ssl-cert-snakeoil.pem"
+FALLBACK_KEY="/etc/ssl/private/ssl-cert-snakeoil.key"
+
+class ThreadedTCPServer(socketserver.ThreadingMixIn, socketserver.TCPServer):
+    pass
+
+class ThreadedTCPRequestHandler(socketserver.BaseRequestHandler):
+    def create_context(self, certfile, keyfile, first=False):
+        ssl_context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
+        ssl_context.set_ciphers('ECDHE+AESGCM')
+        ssl_context.set_alpn_protocols(["acme-tls/1"])
+        ssl_context.options |= ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1
+        if first:
+            ssl_context.set_servername_callback(self.load_certificate)
+        ssl_context.load_cert_chain(certfile=certfile, keyfile=keyfile)
+        return ssl_context
+
+    def load_certificate(self, sslsocket, sni_name, sslcontext):
+        print("Got request for %s" % sni_name)
+        if not re.match(r'^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][-_.a-zA-Z0-9]{0,61}[a-zA-Z0-9]))\.([a-zA-Z]{2,13}|[a-zA-Z0-9-]{2,30}.[a-zA-Z]{2,3})$', sni_name):
+            return
+
+        certfile = os.path.join(ALPNDIR, "%s.crt.pem" % sni_name)
+        keyfile = os.path.join(ALPNDIR, "%s.key.pem" % sni_name)
+
+        if not os.path.exists(certfile) or not os.path.exists(keyfile):
+            return
+
+        sslsocket.context = self.create_context(certfile, keyfile)
+
+    def handle(self):
+        if PROXY_PROTOCOL:
+            buf = b""
+            while b"\r\n" not in buf:
+                buf += self.request.recv(1)
+
+        ssl_context = self.create_context(FALLBACK_CERTIFICATE, FALLBACK_KEY, True)
+        newsock = ssl_context.wrap_socket(self.request, server_side=True)
+
+if __name__ == "__main__":
+    HOST, PORT = "0.0.0.0", 10443
+
+    server = ThreadedTCPServer((HOST, PORT), ThreadedTCPRequestHandler, bind_and_activate=False)
+    server.allow_reuse_address = True
+    try:
+        server.server_bind()
+        server.server_activate()
+        server.serve_forever()
+    except:
+        server.shutdown()
+```
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
new file mode 100644
index 0000000..12b2ff5
--- /dev/null
+++ b/docs/troubleshooting.md
@@ -0,0 +1,52 @@
+# Troubleshooting
+
+Generally if the following information doesn't provide a solution to your problem please take a look at existing issues (search for keywords) before creating a new one.
+
+## "No registration exists matching provided key"
+
+You probably changed from staging-CA to production-CA (or the other way).
+
+Currently dehydrated doesn't detect a missing registration on the selected CA,
+the current workaround is to move `private_key.pem` (and, if you care, `private_key.json`) out of the way so the scripts generates and registers a new one.
+
+This will hopefully be fixed in the future.
+
+## "Error creating new cert :: Too many certificates already issued for: [...]"
+
+This is not an issue with dehydrated but an API limit with boulder (the ACME server).
+
+At the time of writing this you can only create 5 certificates per domain in a sliding window of 7 days.
+
+## "Certificate request has 123 names, maximum is 100."
+
+This also is an API limit from boulder, you are requesting to sign a certificate with way too many domains.
+
+## Invalid challenges
+
+There are a few factors that could result in invalid challenges.
+
+If you are using HTTP validation make sure that the path you have configured with WELLKNOWN is readable under your domain.
+
+To test this create a file (e.g. `test.txt`) in that directory and try opening it with your browser: `http://example.org/.well-known/acme-challenge/test.txt`. Note that if you have an IPv6 address, the challenge connection will be on IPv6. Be sure that you test HTTP connections on both IPv4 and IPv6. Checking the test file in your browser is often not sufficient because the browser just fails over to IPv4.
+
+If you get any error you'll have to fix your web server configuration.
+
+## DNS invalid challenge since dehydrated 0.6.0 / Why are DNS challenges deployed first and verified later?
+
+Since Let's Encrypt (and in general the ACMEv2 protocol) now supports wildcard domains there is a situation where DNS caching can become a problem.
+If somebody wants to validate a certificate with `example.org` and `*.example.org` there are two tokens that have to be deployed on `_acme-challenge.example.org`.
+
+If dehydrated would deploy and verify each token on its own the CA would cache the first token on `_acme-challenge.example.org` and the next challenge would simply fail.
+Let's Encrypt uses your DNS TTL with a max limit of 5 minutes, but this doesn't seem to be part of the ACME protocol, just some LE specific configuration,
+so with other CAs and certain DNS providers who don't allow low TTLs this could potentially take hours.
+
+Since dehydrated now deploys all challenges first that no longer is a problem. The CA will query and cache both challenges, and both authorizations can be validated.
+Some hook-scripts were written in a way that erases the old TXT record rather than adding a new entry, those should be (and many of them already have been) fixed.
+
+There are certain DNS providers which really only allow one TXT record on a domain. This is really odd and you should probably contact your DNS provider and ask them
+to fix this.
+
+If for whatever reason you can't switch DNS providers and your DNS provider only supports one TXT record and doesn't want to fix that you could try splitting your
+certificate into multiple certificates and add a sleep in the `deploy_cert` hook.
+If you can't do that or really don't want to please leave a comment on https://github.com/lukas2511/dehydrated/issues/554,
+if many people are having this unfixable problem I might try to implement a workaround.
diff --git a/docs/wellknown.md b/docs/wellknown.md
new file mode 100644
index 0000000..f5a9305
--- /dev/null
+++ b/docs/wellknown.md
@@ -0,0 +1,78 @@
+# WELLKNOWN
+
+With `http-01`-type verification (default in this script, there is also support for [dns based verification](dns-verification.md)) Let's Encrypt (or the ACME-protocol in general) is checking if you are in control of a domain by accessing a verification file on an URL similar to `http://example.org/.well-known/acme-challenge/m4g1C-t0k3n`.  
+It will do that for any (sub-)domain you want to sign a certificate for.
+
+At the moment you'll need to have that location available over normal HTTP on port 80 (redirect to HTTPS will work, but starting point is always HTTP!).
+
+dehydrated has a config variable called `WELLKNOWN`, which corresponds to the directory which should be served under `/.well-known/acme-challenge` on your domain. So in the above example the token would have been saved as `$WELLKNOWN/m4g1C-t0k3n`.
+
+If you only have one docroot on your server you could easily do something like `WELLKNOWN=/var/www/.well-known/acme-challenge`, for anything else look at the example below.
+
+## Example Usage
+
+If you have more than one docroot (or you are using your server as a reverse proxy / load balancer) the simple configuration mentioned above wouldn't work, but with just a few lines of webserver configuration this can be solved.
+
+An example would be to create a directory `/var/www/dehydrated` and set `WELLKNOWN=/var/www/dehydrated` in the scripts config.
+
+You'll need to configure aliases on your Webserver:
+
+### Nginx example config
+
+With Nginx you'll need to add this to any of your `server`/VHost config blocks:
+
+```nginx
+server {
+  [...]
+  location ^~ /.well-known/acme-challenge {
+    alias /var/www/dehydrated;
+  }
+  [...]
+}
+```
+
+### Apache example config
+
+With Apache just add this to your config and it should work in any VHost:
+
+```apache
+Alias /.well-known/acme-challenge /var/www/dehydrated
+
+<Directory /var/www/dehydrated>
+        Options None
+        AllowOverride None
+
+        # Apache 2.x
+        <IfModule !mod_authz_core.c>
+                Order allow,deny
+                Allow from all
+        </IfModule>
+
+        # Apache 2.4
+        <IfModule mod_authz_core.c>
+                Require all granted
+        </IfModule>
+</Directory>
+```
+
+### Lighttpd example config
+
+With Lighttpd just add this to your config and it should work in any VHost:
+
+```lighttpd
+server.modules += ("alias")
+alias.url += (
+ "/.well-known/acme-challenge/" => "/var/www/dehydrated/",
+)
+```
+
+
+### Hiawatha example config
+
+With Hiawatha just add an alias to your config file for each VirtualHost and it should work:
+```hiawatha
+VirtualHost {
+    Hostname = example.tld subdomain.mywebsite.tld
+    Alias = /.well-known/acme-challenge:/var/www/dehydrated
+}
+```