diff options
| -rw-r--r-- | debian/control | 47 | ||||
| -rw-r--r-- | debian/install | 3 |
2 files changed, 33 insertions, 17 deletions
diff --git a/debian/control b/debian/control index 4a7f4a5..bfedf37 100644 --- a/debian/control +++ b/debian/control @@ -1,5 +1,5 @@ Source: letsencrypt-tiny -Section: mail +Section: utils Priority: optional Maintainer: Guilhem Moulin <guilhem@guilhem.org> Build-Depends: debhelper (>= 9) @@ -11,18 +11,37 @@ Package: letsencrypt-tiny Architecture: all Depends: ${misc:Depends}, ${perl:Depends}, libcrypt-openssl-bignum-perl, libcrypt-openssl-rsa-perl, - libwww-perl, libjson-perl | libjson-xs-perl, - openssl, netcat-openbsd | netcat-traditional -Recommends: liblwp-protocol-https-perl, socat + libwww-perl, libjson-perl, libconfig-tiny-perl, + libnet-ssleay-perl, openssl +Recommends: liblwp-protocol-https-perl Conflicts: letsencrypt Description: Tiny ACME client for Let's Encrypt - This tiny ACME client written is with process isolation and minimal privileges - in mind. It is divided into three components: - 1. the "master" process, which runs as root and is the only component - with access to the private key material (both account and server keys); - 2. the actual ACME client, which runs as a separated user ID, builds ACME - requests and dialogues with the remote ACME server (data to be signed is - written to a pipe shared with the master process, which replies with its - SHA-256 signature); and - 3. an optional webserver, which runs as www-data:www-data and listen on port - 80 to server ACME challenges. + Tiny ACME client written with process isolation and minimal privileges in + mind. It is divided into four components, each with its own executable: + . + * A process to manage the account key and issue SHA-256 signatures needed for + each ACME command. (This process binds to a UNIX-domain socket to reply to + signature requests from the ACME client.) One can use the UNIX-domain + socket forwarding facility of OpenSSH 6.7 and later to run this process on + a different host. + . + * A "master" process, which runs as root and is the only component + with access to the private key material of the server keys. It is used to + fork the ACME client (and optionally the ACME webserver) after dropping + root privileges. For certificate issuances, it also generates Certificate + Signing Requests, then verifies the validity of the issued certificate, and + optionally reloads or restarts services. + . + * An actual ACME client, which builds ACME commands and dialogues with + the remote ACME server. Since ACME commands need to be signed with the + account key, the "master" process passes the UNIX-domain socket of the + account key manager to the ACME client: data signatures are requested by + writing the data to be signed to the socket. + . + * For certificate issuances, an optional webserver, which is spawned + by the "master" process when no service is listening on the HTTP port. + (The only challenge type currently supported is "http-01", which requires a + webserver to answer challenges.) That webserver only processes GET and + HEAD requests under the "/.well-known/acme-challenge/" URI. By default + some iptables(1) rules are automatically installed to open the HTTP port, + and removed afterwards. diff --git a/debian/install b/debian/install deleted file mode 100644 index 9489976..0000000 --- a/debian/install +++ /dev/null @@ -1,3 +0,0 @@ -letsencrypt /usr/sbin -client webserver /usr/lib/letsencrypt-tiny -*.pem /usr/share/letsencrypt-tiny |