NAME

       dehydrated - ACME client implemented as a shell-script

SYNOPSIS

       dehydrated [command [argument]] [argument [argument]] ...

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
       --register --accept-terms 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 Subject Alternative Name (SAN) field.

       For the next step, one way of verifying domain name  ownership  needs  to  be  configured.
       Dehydrated implements http-01 and dns-01 verification.

       The  http-01  verification  provides proof of ownership by providing a challenge token. In
       order to do that, the directory referenced in the WELLKNOWN config variable  needs  to  be
       exposed  at  http://{domain}/.well-known/acme-challenge/,  where  {domain} is every domain
       name specified in domains.txt.  Dehydrated does not provide its own  challenge  responder,
       but  relies on an existing web server to provide the challenge response.  See wellknown.md
       for configuration examples of popular web servers.

       The dns-01 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 dns-
       verification.md 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
       dehydrated -c manually.

       After a successful run, certificates are stored in  /etc/dehydrated/certs/{domain},  where
       {domain} is the domain name in the first column of domains.txt.

OPTIONS

       Commands

       --version, -v
              Print version information

       --register
              Register account key

       --account
              Update account contact information

       --cron, -c
              Sign/renew non-existent/changed/expiring certificates.

       --signcsr, -s path/to/csr.pem
              Sign a given CSR, output CRT on stdout (advanced usage)

       --revoke, -r path/to/cert.pem
              Revoke specified certificate

       --cleanup, -gc
              Move unused certificate files to archive directory

       --help, -h
              Show help text

       --env, -e
              Output configuration variables for use in other scripts

       Parameters

       --accept-terms
              Accept CAs terms of service

       --full-chain, -fc
              Print full chain when using --signcsr

       --ipv4, -4
              Resolve names to IPv4 addresses only

       --ipv6, -6
              Resolve names to IPv6 addresses only

       --domain, -d domain.tld
              Use specified domain name(s) instead of domains.txt entry (one certificate!)

       --keep-going, -g
              Keep   going   after   encountering   an  error  while  creating/renewing  multiple
              certificates in cron mode

       --force, -x
              Force renew of certificate even if it is longer valid than value in RENEW_DAYS

       --no-lock, -n
              Don't use lockfile (potentially dangerous!)

       --lock-suffix example.com
              Suffix lockfile name with a string (useful for use with -d)

       --ocsp Sets option in CSR indicating OCSP stapling to be mandatory

       --privkey, -p path/to/key.pem
              Use specified private key instead of account key (useful for revocation)

       --config, -f path/to/config
              Use specified config file

       --hook, -k path/to/hook.sh
              Use specified script for hooks

       --out, -o certs/directory
              Output certificates into the specified directory

       --challenge, -t [http-01|dns-01]
              Which challenge should be used? Currently http-01 and dns-01 are supported

       --algo, -a [rsa|prime256v1|secp384r1]
              Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1

DIAGNOSTICS

       The program exits 0 if everything was fine, 1 if an error occurred.

BUGS

       Please  report  any  bugs   that   you   may   encounter   at   the   project   web   site
       ⟨https://github.com/lukas2511/dehydrated/issues⟩.

AUTHOR

       Dehydrated  was  written  by  Lukas  Schauer.  This  man  page  was  contributed by Daniel
       Molkentin.

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.

SEE ALSO

       Full documentation along with configuration examples are provided in the docs directory of
       the distribution, or at ⟨https://github.com/lukas2511/dehydrated/tree/master/docs⟩.