Ubuntu
lacme package

lacme 0.8.2-1 source package in Ubuntu

Changelog

lacme (0.8.2-1) unstable; urgency=medium

  * New upstream bugfix release.
    + client: Handle "ready" → "processing" → "valid" status change during
      newOrder, instead of just "ready" → "valid".  The latter may be what we
      observe when the server is fast enough, but according to RFC 8555 sec.
      7.1.6 the state actually transitions via "processing" state and we need
      to account for that.  Closes: #1034834.
    + Test suite: Point stretch's archive URL to archive.d.o.

 -- Guilhem Moulin <email address hidden>  Tue, 25 Apr 2023 20:08:21 +0200

Upload details

Uploaded by:
Guilhem Moulin
Uploaded to:
Sid
Original maintainer:
Guilhem Moulin
Architectures:
all
Section:
misc
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Noble release universe misc
Mantic release universe misc

Builds

Mantic: [FULLYBUILT] amd64

Downloads

File Size SHA-256 Checksum
lacme_0.8.2-1.dsc 1.8 KiB 939f12a5ea55f59f5b6344925259e62a3271f820afa14a634151e876db122a7c
lacme_0.8.2.orig.tar.gz 81.5 KiB 9bf193193cc5d496610d489a63800b77f797a2e05daddf54e27dd890f174f236
lacme_0.8.2-1.debian.tar.xz 15.6 KiB ea84f6c5e0bec6d70e611deaf0310b037a1d6b30c8afaa188e700c3bf9be8272

Available diffs

No changes file available.

Binary packages built by this source

lacme: 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.

lacme-accountd: 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.