psign: Best Code Signing CLI Tools for Windows Engineers in 2026

What Is psign?

psign is a Rust port of the Windows SDK signtool.exe behavior built by Devolutions. It is one of the best Code Signing CLI Tools for Windows release engineers, and it covers seven major command families plus portable subcommands for signing, verification, timestamping, and inspection. The project targets teams that need Authenticode parity, RFC3161 timestamps, and repeatable signing flows across Windows and non-Windows hosts.

psign matters because it is not just a wrapper around an existing binary. The repo states that its CI includes differential parity tests against the native Windows tool where fixtures allow, which is the right signal for anyone shipping signed binaries, MSIX packages, or package artifacts through a CI pipeline. If your build system depends on deterministic release signing instead of manual GUI steps, psign is built for that job.

Quick Overview

Who Should Use psign?

psign is the right fit when signing is part of a release pipeline, not an afterthought.

• Release engineers shipping Windows artifacts who need signtool.exe-style flows for PE files, MSIX/AppX, NuGet packages, ClickOnce manifests, and RDP files.
• Platform teams standardizing CI signing across Windows runners and containerized or Linux-based build agents that cannot depend on native Windows trust APIs.
• Security-minded build owners who want explicit timestamping, inspectable PKCS#7 output, and repeatable certificate selection from stores, PFX files, or remote signing services.
• Teams migrating away from ad hoc scripts that call multiple signing utilities, because psign centralizes orchestration and inspection under one CLI surface.

Not ideal for:

• Teams that only need a GUI signing workflow and never touch CI.
• Projects that want a commercial support contract bundled with the tool itself.
• Workloads that require every obscure signtool.exe edge case and have no tolerance for parity gaps.

Key Features of psign

• Windows-compatible core commands — verify, remove, and catdb map directly to native signtool.exe-style behavior and use WinTrust and CryptSIP where Windows APIs are required. That keeps trust evaluation aligned with the host OS instead of reimplementing policy guesses in user space.
• Authenticode signing with native Windows primitives — sign uses the Rust mssign32 path through SignerSignEx3, with PFX and system-store certificate selection plus RFC3161 sign-time timestamping. That is the path you want when the build agent has access to the Windows signing stack and you care about parity.
• Structured signature inspection — inspect-signature emits JSON for PKCS#7 signers, timestamp OIDs, and nested signatures such as 1.3.6.1.4.1.311.2.4.1. That is much easier to diff in CI than scraping human-oriented console output.
• RDP signing support — rdp is a Rust port of rdpsign.exe and understands SignScope and Signature records over the secure-settings blob. That makes Remote Desktop file signing a first-class workflow instead of a separate one-off utility.
• Portable certificate store — cert-store persists certificates under ~/.psign/cert-store by default, with Windows-style store and thumbprint selection. That is useful when you want reproducible local signing state without relying on machine-wide certificate stores.
• Cross-platform portable mode — portable ... routes digest, verification, trust, signing, package, RFC3161, and remote-hash helpers through Rust implementations that avoid Win32 APIs. It is the practical path for Linux CI, macOS developers, or Windows environments where native APIs are not available.
• Orchestration for complex packaging flows — code supports --dry-run and --plan-json, nested ZIP and OPC containers, Azure Key Vault, Artifact Signing, PE/WinMD, NuGet, VSIX, MSIX/AppX, ClickOnce, and App Installer scenarios. If you have ever chained five scripts together to sign a release bundle, this is the command surface that replaces that mess.

psign vs Alternatives

If your release process includes signing plus packaging, psign sits closer to the command-line end of the spectrum than GUI release tooling. For adjacent workflow patterns, browse all CLI Tools or DevOps Automation tools.

Pick signtool.exe when you are already on Windows and want the Microsoft-maintained reference implementation with no extra abstraction. It is still the baseline for Windows-specific behavior, especially when you need to validate a tricky signing failure against the native stack.

Pick AzureSignTool when your signing policy is centered on Azure Key Vault and you do not need psign’s broader packaging and inspection surface. It is a narrower tool, which can be an advantage if your only job is cloud-based signing of a small artifact set.

Pick osslsigncode when you need straightforward signing support in environments where Windows semantics are not required. It is useful, but it does not try to mirror the full Authenticode and packaging behavior that psign targets.

How psign Works

psign works by splitting execution into two trust models: a Windows mode that binds to native APIs, and a portable mode that reimplements the core operations in Rust. The design is intentional, because signing is not just hashing plus embedding a blob; it is a combination of certificate selection, digest policy, signature encoding, timestamping, and trust verification across multiple container formats.

The portable layer pulls behavior into Rust crates such as psign-sip-digest, psign-authenticode-trust, psign-opc-sign, psign-codesigning-rest, and psign-azure-kv-rest. That gives the project a single CLI entry point while still preserving separate abstractions for PE files, OPC-based packages, PKCS#7 payloads, and remote signing backends like Azure Artifact Signing and Azure Key Vault.

A typical portable signing flow looks like this:

cargo build -p psign --bin psign-tool --locked
psign-tool portable sign-pe --cert cert.der --key key.pk8 --output signed.exe unsigned.exe
psign-tool portable trust-verify-pe signed.exe --anchor-dir anchors

The first command builds the unified CLI, the second signs a PE file with a local RSA key, and the third verifies the result against explicit trust anchors. In practice, that means you can wire psign into CI, sign an artifact, and immediately verify the output without switching tools or manually inspecting the container.

The code orchestration path is the other important architectural decision. It acts like a release-signing planner, with --dry-run and --plan-json allowing you to inspect what will be signed before any mutation happens, which is exactly what you want when the input set includes nested ZIPs, manifest files, and bundle containers.

Pros and Cons of psign

Pros:

• Close signtool parity — the repo explicitly validates behavior against signtool.exe where CI fixtures allow, which lowers the risk of hidden differences during release validation.
• Portable execution path — portable mode avoids WinVerifyTrust and OS trust-store dependence, which makes Linux and macOS workflows viable.
• Broad artifact coverage — PE, WinMD, NuGet, MSIX/AppX, VSIX, ClickOnce, RDP, CAB, and generic ZIP flows are all represented in the CLI surface.
• Inspection-first workflow — inspect-signature returns JSON, so it fits automated checks, diffing, and policy gates better than human-only console output.
• Remote signing support — Azure Key Vault and Artifact Signing integration lets teams keep private keys out of build agents.
• Repo-local and global distribution options — you can build from source with Cargo or consume the .NET tool package from NuGet.org.

Cons:

• Windows parity still has edge cases — the repo acknowledges parity gaps versus native signtool.exe, AzureSignTool, and Azure Artifact Signing in some scenarios.
• Some workflows require external services — Key Vault and Artifact Signing flows depend on Azure infrastructure and network access.
• The surface area is large — teams only needing one small signing action may find the command set heavier than necessary.
• Windows-mode behavior depends on native APIs — if a host lacks the expected SIP or trust components, you must switch to portable mode or adjust the environment.
• Documentation depth is uneven by workflow — the repo is clear about commands, but real teams will still need to map their package types to the right subcommand and flags.

Getting Started with psign

The fastest way to start with psign is to install the published psign-tool package or build the binary from source, then run --help and pick the backend mode that matches your host. If you are evaluating it in CI, start with portable mode first, because it reduces dependency on machine-specific Windows state.

dotnet tool install -g Devolutions.Psign.Tool
psign-tool --help

# Optional source build path
cargo build -p psign --bin psign-tool --locked

After installation, psign-tool gives you the CLI entry point, and --help exposes the Windows and portable command families. On a Windows release agent, you can stay in auto mode and let psign choose the native path; on Linux or macOS, you should explicitly pick portable commands and provide the certificate and key material the workflow expects.

For the first real run, start with a read-only command such as signature inspection or verification before you sign production artifacts. That reduces the chance of learning the CLI surface by mutating a release binary on your first attempt.

Verdict

psign is the strongest option for Windows-centric code signing when you need signtool parity plus a portable fallback. Its best strength is the split architecture that covers native Windows APIs and Rust-based cross-platform flows in one CLI. The caveat is that parity is not perfect in every edge case, so teams with strict release policy should validate their own artifact matrix before adopting it broadly. I recommend psign for CI-heavy teams that sign more than one package format.