v0.2.4

Binaries and packages for every platform, and a Windows service

ghcr.io/certpilot/agent:0.2.4     linux/amd64, linux/arm64
go install github.com/certpilot/certpilot-agent/cmd@v0.2.4

Hosts that could not run the agent as shipped now have a way in.

• Binaries: this release has archives for Linux (amd64, arm64, armv7, 386), Windows (amd64, arm64), macOS and FreeBSD, with a SHA256SUMS file (#13).
• Packages: a .deb and an .rpm for each Linux architecture. They install the binary, a daemon unit and a 5-minute timer, and enable neither until the host has enrolled. Removing the package keeps the host's identity (#15).
• Windows service: certpilot-agent service install starts the agent with Windows, restarts it after a failure and logs to the Event Log (#16).
• Proxies: enrolment and every later request go through the proxy named in HTTPS_PROXY. This already worked and is now tested (#14).
• Docs: docs/agent.md has a section for hosts with no systemd, no daemon, a proxy or no root (#14).

v0.2.3

Profiled keys are private to their owner unless a group is named

ghcr.io/certpilot/agent:0.2.3     linux/amd64, linux/arm64
go install github.com/certpilot/certpilot-agent/cmd@v0.2.3

A profile writes the private key 0600 unless the destination names a group (#7).

• The problem: the nginx, Apache, HAProxy, Caddy and Tomcat profiles wrote the key 0640 whether or not a group was named. With no group, that made the key readable by every member of the owner's group. The core's own inventory flags a key like that as private_key_readable, CRITICAL, so a host set up by the documented profile reported itself as exposed.
• What the agent does now: it writes the key 0600, or 0640 when the destination names a group, because naming one says which group should read it. An explicit key_mode is still obeyed exactly. certpilot-agent profiles and the nginx and HAProxy guides say the same.
• Existing hosts: a key already on disk keeps its mode until the next install replaces the file.

Verified with real services: nginx, Apache, HAProxy, Caddy and Tomcat each loaded a certificate the agent installed, with the key at 0600.

A renewal tells the core which certificate it replaces (#8).

The agent now sends renews with the ID of the certificate it holds. Core v0.2.1 uses it to update that record rather than add a second one (certpilot/certpilot#127). Core v0.2.0 ignores the field, so this agent works with it as before.

Verified end to end on an nginx host, against a core built from certpilot/certpilot#127: renewing with this agent kept one certificate record and raised its renewal count.

Known issues: none open against the agent.

v0.2.2

The agent will not renew a certificate before it was issued

ghcr.io/certpilot/agent:0.2.2     linux/amd64, linux/arm64
go install github.com/certpilot/certpilot-agent/cmd@v0.2.2

A renew_after from before the certificate was issued is no longer obeyed (#5).

• The problem: a core before v0.2.0 computed renew_after with no floor. A certificate shorter than the renewal lead time, such as a 6-day ACME certificate under the default 30 days, got a renew_after that had already passed. The agent obeyed it and ordered a replacement on every five-minute cycle, 288 orders a day for one name (certpilot/certpilot#109).
• What the agent does now: when renew_after falls before the certificate was issued, the agent renews when a third of the certificate's life remains. That is the rule core v0.2.0 itself applies, so a host talking to an older core behaves as if the core were fixed. It logs a warning on every cycle until the renewal is due, because the warning means the core needs upgrading.
• Unchanged: every other renew_after is obeyed exactly. The core decides when to renew.

Verified end to end: an agent built from this change was run against a core with the old arithmetic. That core said renew after 24 days before issue. The agent warned, scheduled the renewal for day 4, and a second cycle left the certificate alone.

Nothing else changed for a host.

Known issues: none open against the agent. Core v0.2.0 fixes both core issues the v0.2.1 notes listed, certpilot/certpilot#107 and #109. This release adds the agent's own check against #109.

v0.2.1

The agent now reports its own version when installed with go install

v0.2.0 installed that way reported 0.1.0-dev, and so did everything it sent the core: enrolment and every heartbeat. Only the container image stamped the version. An unstamped build now reads the version Go recorded when it built the module, so go install …@v0.2.1 reports 0.2.1, the same as the image. A build with nothing to read still says 0.1.0-dev rather than guess (#3).

ghcr.io/certpilot/agent:0.2.1     linux/amd64, linux/arm64
go install github.com/certpilot/certpilot-agent/cmd@v0.2.1

Nothing else changed for a host.

Known issues, in the core: a certificate shorter than its renewal lead time renews on every cycle (certpilot/certpilot#109), and renewing an agent-held certificate by hand makes CertPilot hold its private key (certpilot/certpilot#107).

v0.2.0

The first release published from the agent's own repository.

ghcr.io/certpilot/agent:0.2.0     linux/amd64, linux/arm64

Same image name as before, so nothing that pulls ghcr.io/certpilot/agent has to change. Only the source repository moved.

A minor rather than a patch bump. The agent last shipped inside the core's v0.1.1 release, and has since gained:

• Windows. The agent builds and runs there, and a private key stays readable by its owner alone: on Windows that is an ACL, not a file mode (certpilot/certpilot#69).
• The Windows certificate store and an iis profile, because IIS, Exchange and ADFS bind a certificate from the store, not from a file (certpilot/certpilot#70).
• A named private key entry in a PKCS#12 keystore (certpilot/certpilot#66).

CI at this commit ran IIS end to end — install, renew and roll back against a running IIS — and the ACL on a real Windows kernel, and completed the lifecycle against the core. All passed.

Known issues

• Installed with go install, the binary reports 0.1.0-dev, to the core as well, on enrolment and every heartbeat. The image reports 0.2.0. Fixed on main (#3), not yet released.
• In the core: a certificate shorter than its renewal lead time renews on every cycle (certpilot/certpilot#109), and renewing an agent-held certificate by hand makes CertPilot hold its private key (certpilot/certpilot#107).