acertmgr

ACERTMGR

This is an automated certificate manager using ACME/letsencrypt with minimal dependencies.

Running ACERTMGR

The main file acertmgr.py is intended to be run regularly (e.g. as daily cron job / systemd timer) as root or user with enough privileges.

Requirements

• Python (2.7+ and 3.5+ should work)
• cryptography>=0.6

Optional requirements (to use specified features)

• PyYAML: to parse YAML-formatted configuration files
• dnspython: used by dns.* challenge handlers
• idna: to allow automatic conversion of unicode domain names to their IDNA2008 counterparts
• cryptography>=2.1: for creating certificates with the OCSP must-staple flag (cert_must_staple)
• cryptography>=2.6: for usage of Ed25519/Ed448 keys

Setup

You should decide which challenge mode you want to use with acertmgr:

• webdir: In this mode, responses to challenges are put into a directory, to be served by an existing webserver
• standalone: In this mode, challenges are completed by acertmgr directly. This starts a webserver to solve the challenges, which can be used standalone or together with an existing webserver that forwards request to a specified local port/address.
• dns.*: This mode puts the challenge into a TXT record for the domain (usually _acme-challenge.) where it will be parsed from by the authority
• dns.* (Alias mode): Can be used similar to the above but allows redirection of _acme-challenge. to any other (updatable domain) defined in dns_updatedomain via CNAME (e.g. _acme-challenge.example.net IN CNAME bla.foo.bar with dns_updatedomain="bla.foo.bar" in domainconfig)
• dns.nsupdate: Updates the TXT record using RFC2136

You can optionally provide the private key files to be used with the ACME protocol (if you do not they will be automatically created):

• The account private key is (by default) expected at /etc/acertmgr/account.key (used to register an account with the authorities server)
• The domain private keys are (by default) expected at /etc/acertmgr/{cert_id}.key
• If you are missing these keys, they will be created for you (using RSA with the configured key_length) or you can create them using e.g. openssl genrsa 4096 > /etc/acertmgr/account.key
• Do not forget to set proper permissions of the keys using chmod 0400 /etc/acertmgr/*.key if you created those manually

Finally, you need to setup the configuration files, as shown in the next section. While testing, you can use the acme-staging authority instead, in order to avoid issuing too many certificates.

Authorities (e.g. our default Let's Encrypt) will require you to accept their Terms of Service. This can be done either in the optional global config file and/or via a commandline parameter (see acertmgr.py --help).

Configuration

Configuration examples are included in the docs/ directory. All configuration files can use yaml (requires PyYAML) or json syntax. (Note: The JSON examples may be incomplete due to inability to express comments in JSON)

Unless specified with a commandline parameter (see acertmgr.py --help) the optional global configuration is read from /etc/acertmgr/acertmgr.conf. Domains for which certificates should be obtained/renewed are be configured in /etc/acertmgr/*.conf (the global configuration is always excluded if it is in the same directory). By default the directory (work_dir) containing the working data (csr,certificate,key and ca files) is located at /etc/acertmgr/.

4 configuration contexts are known (domainconfig (d) > globalconfig (g) > commandline (c) > built-in defaults) with the following directives (subject to change, usual usage context written bold):

Security

Please keep the following in mind when using this software:

• DO read the source code, since it (usually) will be run as root
• Make sure that your configuration files are NOT writable by other users - arbitrary commands can be executed after updating certificates
• Try to run this program non-privileged if possible. This requires you to:
  • Create a dedicated user for acertmgr (e.g. acertmgr)
  • Run a acertmgr as that user (add acertmgr to that users cron!)
  • Access rights to read/write all files configured with the created user
  • Run any programs/scripts defined on cert update as the created user (might need work-arounds with sudo or wrapper scripts)