Signing Keys

IronFlock signs everything that devices and appliances install. Each device and each appliance checks the signature against keys it already holds, before it runs or uses what it downloaded. This page lists those keys, what each one signs, and how a key is replaced (rotated) without leaving a device or an appliance unable to check its next update.

The Keys

The two OpenPGP keys can be downloaded for a check by hand: the appliance key from https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc (see Verify the Installer Before the First Installation), the bootstrap key from https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc (see Optional: Verify the Installer First). Compare the fingerprint gpg reports with the one on this page. The device agent’s keys are built into the agent; there is nothing to check by hand.

On Windows, the device agent checks every update and every frpc.exe it downloads against the code signing root built into it: the file must carry a valid signature by a signer certificate that this root issued. From version 1.5.6 on, a file that fails the check is deleted and not run; versions 1.5.4 and 1.5.5 only logged the failure. The signer certificate is checked at the time of the check, so a Windows device whose clock is outside the certificate’s validity does not update until its clock is right. At every start the agent also checks its own executable and writes codesign: self-check passed or codesign: self-check FAILED to its log, C:\ProgramData\IronFlock\DeviceAgent\device-agent.log; a device that logs FAILED refuses updates signed like the agent it runs.

The agent’s installer also adds the code signing root to the computer’s trusted root certificates. The agent’s check does not need it there, so a device installed before the installer did this checks its updates the same way. To check that it is the root on this page, run Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter in PowerShell; the thumbprint must be 6083E7E2446B8C95A6F6B2E3CFE354AE02859196. With the root there, Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } } shows Valid; Windows writes the serial number with a leading 00, as 00D137272B35F0ED5211219674E8B052B4. Device agents before version 1.5.4, and frpc.exe up to frp version 0.71.1, carry the previous Windows signer certificate, serial number 481360741E254378C38A5236940BFFA44CFDD809, issued by the same root. It signs nothing new; the agent accepts its signatures until the certificate ends in October 2028.

Every service image of the IronFlock platform released from 6 November 2026 on carries its build provenance as signed attestations, one for each platform of the image, in the SLSA v1 provenance format: the source repository, the commit, the build and the base images it was built from. The attestations are stored with the image in the registry and are not recorded in a public transparency log. To check an image you can pull, save the public key below as image-provenance.pub, compare its fingerprint with the one in the table (first command), and verify the image by its digest with cosign 3 or later (second command):

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEjyfZEmjD3ErGVqBO5fsNl+aPy+oO
vDGv410tK7HUUZgD+EMbmXYq/qhXuJ0QhjYi/zDEozRRhLT3AnsgIOabrQ==
-----END PUBLIC KEY-----

openssl pkey -pubin -in image-provenance.pub -outform DER | openssl dgst -sha256
cosign verify-attestation --key image-provenance.pub --type slsaprovenance1 --insecure-ignore-tlog <image>@sha256:<digest>

--insecure-ignore-tlog only tells cosign not to look for a transparency log entry; the signature is still checked against the key. Each attestation names its platform in predicate.buildDefinition.internalParameters.targetPlatform. An image released earlier carries no signed provenance, so an IronFlock version can contain images with and without it until each of its services has been released again.

The provenance meets SLSA Build Level 3. Each image is built on a fresh machine of a hosted build service, apart from every other build and without a build cache shared with other builds. The provenance is signed in a separate step on another machine, which runs none of the code being built and checks the source repository, the commit and the build the provenance names; only this step can use the key. An image can also contain data that an earlier step of the same release prepared, for example a search index; the provenance names such an input, not its content. Some images released on 5 November 2026 already carry signed provenance; it meets Level 2, because the key was not yet limited to the signing step.

How the Keys Are Kept

• The keys on this page cannot be exported, except the code signing root. Their private keys are held in IronFlock’s key management, and signing happens there. The code signing root signs no software, only the certificate of the Windows signer, and is used only when that certificate is replaced.
• Releases are signed by their release pipeline. The key a product’s releases are signed with can be used only by that product’s automated release, after its checks and tests have passed.
• The device agent trusts two independent keys. New releases are signed with the first. The second signed the earlier releases, and it still signs, by hand, the updates for older agents and older ironflock-init versions, which trust only this key. It is also kept for the case that the first can no longer be used; then updates are signed with it, so devices keep updating without any setting that would skip the check.

Rotating a Key

A key is replaced when it reaches the end of its planned lifetime, or at once when it is suspected to be compromised. This section is about the signing keys above; the appliance’s own internal secrets are replaced with ironflock-update --rotate, see Secrets on the Host. A rotation always runs in three steps, so that every device and appliance can check each update along the way:

1. The new key is added. A release adds the new key to the keys a device or an appliance trusts. That release is still signed with the current key, so everything that updates to it accepts it.
2. Signing moves to the new key. Once the field runs a release that trusts both keys, IronFlock signs with the new key. The old key is still trusted during this period.
3. The old key is retired. A later release removes the old key. From then on, a signature by the old key is refused, and the key is listed under Retired Keys.

What this means for each key:

• Appliance release key. An appliance trusts the keys its ironflock-update was written with, so the appliance has to install the release from step 1 before it can check updates signed in step 2. An appliance that was not updated through the whole overlap stops its update before anything changes; run the installer once by hand, checked against the new key, as described in Verify the Installer Before the First Installation.
• Device agent update keys. A device trusts the keys built into the agent it runs. A device that was offline through the whole overlap cannot check updates signed with the new key; reinstall its agent with the device installer, which trusts the new key.
• Bootstrap key. install.sh is downloaded fresh for every installation and carries the key it checks against, so a new key takes effect with the next installer release, without an overlap. Only a check by hand changes: compare against the fingerprint on this page.
• Windows code signing. A Windows device trusts the code signing root, not the signer. A new signer certificate from the same root takes effect with the next release, without an overlap, and nothing needs to be done on a device. Because the agent checks the signer certificate at the time of the check, a file signed with a certificate that has ended is refused; a signer certificate is therefore replaced well before it ends. The root itself is replaced in the three steps above, well before it ends in July 2036; a Windows device that was offline through the whole overlap needs its agent reinstalled. The computer’s trusted root certificates keep the root the installer added, so after a root rotation the PowerShell check above may show only the earlier root; the agent checks against the roots built into it.
• Image provenance key. No device or appliance checks this key, so a new key takes effect with the next image release, without an overlap. An image keeps the attestations it was released with: check it against the key that was in use when it was released, listed on this page or under Retired Keys.

During an overlap, this page lists both keys with their fingerprints, and the release notes announce each step. Nothing needs to be done on an appliance or a device that is kept up to date.

If a key is compromised, IronFlock stops signing with it at once, rotates it as above on a short schedule, and publishes a security advisory.

Retired Keys

None so far.