Provided by: dehydrated_0.6.5-1_all bug

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⟩.