1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Source: lacme
Section: utils
Priority: optional
Maintainer: Guilhem Moulin <guilhem@debian.org>
Build-Depends: debhelper-compat (= 13), jq, pandoc (>= 2.1~)
Rules-Requires-Root: no
Standards-Version: 4.5.1
Homepage: https://git.guilhem.org/lacme/about/
Vcs-Git: https://salsa.debian.org/debian/lacme.git -b debian/latest
Vcs-Browser: https://salsa.debian.org/debian/lacme
Package: lacme
Architecture: all
Depends: adduser,
libconfig-tiny-perl,
libjson-perl,
libnet-ssleay-perl,
libtimedate-perl,
libwww-perl,
openssl (>= 1.1.0~),
${misc:Depends},
${perl:Depends}
Recommends: lacme-accountd (>= 0.8.0), liblwp-protocol-https-perl
Description: ACME client written with process isolation and minimal privileges in mind
lacme is an ACME client which can be used to request X.509 certificates from
ACME service providers such as Let's Encrypt or ZeroSSL. The architecture 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(8) rules are automatically installed to open the HTTP port,
and removed afterwards.
Package: lacme-accountd
Architecture: all
Depends: libconfig-tiny-perl, libjson-perl, ${misc:Depends}, ${perl:Depends}
Recommends: libcrypt-openssl-rsa-perl
Suggests: gpg, openssl
Description: lacme account key manager
lacme is an ACME client which can be used to request X.509 certificates from
ACME service providers such as Let's Encrypt or ZeroSSL. The architecture is
designed with process isolation and minimal privileges in mind, and is divided
into four components:
.
* 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. iptables(8)
rules can optionally be installed to temporarily open the HTTP port.
.
lacme-accountd is the first (account key manager) component. It is the only
component with access to the account key.
|
