Executive Summary
Qwick Cert is a developer-experience platform for Windows code signing (Authenticode) built on Microsoft's Azure Trusted Signing infrastructure. It eliminates the complexity of Azure portal configuration, credential management, and certificate lifecycle operations by wrapping them into a single CLI command and a web dashboard.
At the core of Qwick Cert's architecture is Digest Proxy signing — a model where private keys and Azure credentials never leave the server. The CLI computes a SHA-256 hash locally and sends only the 32-byte digest to the Qwick Cert API. The server signs via Azure, assembles a PKCS#7/CMS signature, and returns it. The CLI embeds the signature and an RFC 3161 timestamp into the PE file.
This architecture provides a fundamentally stronger security posture than traditional code signing approaches — including direct Azure Trusted Signing integration — while delivering a dramatically simpler developer experience.
The Problem with Traditional Code Signing
Private Keys on Developer Machines
Traditional Authenticode signing requires a PFX file or hardware token containing the private key. These long-lived credentials sit on developer machines, shared drives, or CI servers for months or years. A single compromised machine can lead to signed malware distributed under your organization's identity.
EV Certificate Management
Extended Validation certificates cost $300–700/year, require physical hardware tokens, and involve multi-day validation processes. Certificate renewal is manual and error-prone. When a team member leaves, revoking their access to the signing key is often impossible without rotating the entire certificate.
Shared Secrets in CI/CD
Automating code signing in CI/CD pipelines means storing signing credentials as pipeline secrets. These secrets are often long-lived, shared across projects, and accessible to anyone with repository access — each one a potential attack vector in your supply chain.
How Digest Proxy Signing Works
Digest Proxy signing separates the hash computation (which requires access to the binary) from the signing operation (which requires access to credentials). This separation eliminates credential exposure entirely.
Step 1: Compute Authenticode Digest
The developer runs qwick sign ./app.exe. The CLI reads the PE file and computes the Authenticode digest — a SHA-256 hash of the binary's signable content, following the PE/COFF specification. The digest specifically excludes the checksum field, the certificate table entry, and the certificate data directory, ensuring the signature can be embedded without invalidating itself.
Step 2: Send Hash to API
The 32-byte SHA-256 hash is sent to the Qwick Cert API over TLS. The actual binary never leaves the developer's machine. The request includes authentication credentials (API key or OAuth token) and the digest algorithm identifier.
Step 3: Server Signs via Azure
The server validates authentication, checks signing permissions and policies, then calls Azure Trusted Signing's REST API with the digest. Azure performs the cryptographic operation using FIPS 140-2 Level 3 HSMs and returns the raw RSA signature and certificate chain.
Steps 4–5: Assemble and Return
The server assembles Azure's response into a complete PKCS#7/CMS signature blob following the Authenticode specification and returns it to the CLI over TLS.
Step 6: Embed and Timestamp
The CLI embeds the PKCS#7 signature into the PE file's certificate table and obtains an RFC 3161 timestamp from Microsoft's timestamp authority. The timestamped signature ensures the binary remains valid even after the 72-hour signing certificate expires.
Security Properties
Zero credential exposure
Azure credentials never leave the server. A compromised developer machine or CI runner cannot perform unauthorized signing — it has no access to signing keys or Azure secrets.
Hash-only transit
Only a 32-byte SHA-256 digest crosses the network. The binary itself never leaves the developer's machine. The hash alone reveals nothing about the binary's contents.
Server-side audit trail
Every signing operation is logged server-side with user identity, timestamp, IP address, file hash, and certificate profile. Tamper-resistant by design.
RFC 3161 timestamping
Every signature includes a countersignature from Microsoft's timestamp authority, ensuring signatures remain valid for 10+ years beyond certificate expiry.
No client-side Azure SDK
The CLI is a pure HTTP client — no Azure SDK, no DefaultAzureCredential, no AZURE_CLIENT_* environment variables. Eliminates an entire category of configuration errors.
Server-side policy enforcement
Rate limits, signing policies, IP allowlists, and approval workflows are enforced server-side before requests reach Azure. Impossible with direct Azure integration.
Credential Lifecycle
Qwick Cert treats every Azure credential as disposable. Credentials are created on demand, scoped to a single purpose, and destroyed the moment they are no longer needed.
Ephemeral by design
Azure client secrets are generated per signing session with short TTLs. In digest-proxy mode, pooled credentials live for minutes and are reused across requests within that window — then automatically revoked.
Automatic orphan cleanup
If a signing session crashes or a developer walks away, a background process detects stale sessions and force-revokes the Azure credential within minutes. Nothing lingers in your app registration.
Immediate revocation
After every signing operation, the credential is revoked server-side via Microsoft Graph. Even if a session token were intercepted, the underlying Azure secret no longer exists.
Concurrency controls
Azure app registrations support a limited number of simultaneous credentials. Qwick Cert enforces this with a server-side session lock queue — preventing credential sprawl and keeping the attack surface minimal.
Platform Security
Beyond the signing flow itself, the platform is built with defense-in-depth across data isolation, secret storage, and authentication.
Multi-Tenant Isolation
Every database table is scoped by organization. Row-Level Security (RLS) policies ensure that users can only access data belonging to their own organization — enforced at the database layer, not just application code. All data mutations go through the backend API; direct database access through client libraries cannot bypass these policies.
Secret Storage
Azure service principal credentials, Graph refresh tokens, and pooled signing secrets are stored in Supabase Vault using AES-256 encryption. These secrets are accessed only through privileged database functions that are not exposed through any public API surface.
Cryptographic Practices
- Timing-safe comparison — all secret comparisons use constant-time algorithms to prevent timing attacks
- Hashed API keys — API keys are stored as SHA-256 hashes; the plaintext is shown once at creation and never stored
- One-time token rotation — refresh tokens are rotated on every use; the previous token is immediately invalidated
- CSRF protection — double-submit cookie pattern with high-entropy random tokens on all browser state changes
- Secret rotation support — infrastructure secrets support graceful rotation with a previous-key grace period
You Own the Azure Relationship
Qwick Cert is a developer-experience layer, not a certificate authority. Your Azure Trusted Signing account, certificate profile, and app registration remain under your control. If you stop using Qwick Cert, you revoke the service principal access and nothing is left behind. Your signing identity is always yours.
Qwick Cert vs. Native Azure Setup
Azure Trusted Signing is powerful infrastructure. Qwick Cert is the developer experience that makes it usable — with a stronger security model.
| Native Azure | Qwick Cert | |
|---|---|---|
| Setup time | 2–8 hours | 5 minutes |
| Credentials on dev machines | Yes (service principal) | None |
| Credentials in CI/CD | AZURE_CLIENT_* env vars | API key only |
| Credential lifetime | Months or years | N/A (never leaves server) |
| Team access control | Azure RBAC (complex) | Simple roles in dashboard |
| Signing audit trail | Azure Monitor (extra cost) | Built-in, per-signature |
| CI/CD integration | Custom scripting | One-line CLI or GitHub Action |
| Signing policies | Not available | Built-in rules engine |
| Batch signing | Manual scripting | Glob patterns + parallel workers |
| SDK dependencies | Azure SDK on every machine | None (pure HTTP) |
Compliance & Trust
Authenticode Standard Compliance
All signatures produced through Qwick Cert are standard Authenticode signatures, indistinguishable from those produced by signtool.exe. They use the same PE/COFF signature format, the same PKCS#7/CMS structure, and the same certificate chain validation that Windows has used since Windows XP.
RFC 3161 Timestamping
Every signature includes a countersignature from Microsoft's RFC 3161 timestamp authority. Azure Trusted Signing certificates have a 72-hour validity window and rotate automatically — without timestamping, signatures would become invalid within three days. With timestamping, they remain valid for the lifetime of the timestamp authority's certificate (typically 10+ years).
Microsoft-Backed Infrastructure
The actual signing operation is performed by Microsoft's Azure Trusted Signing service using FIPS 140-2 Level 3 certified Hardware Security Modules (HSMs). Qwick Cert is a developer-experience layer on top of this infrastructure, not a replacement for it.
Data Handling
- Binary content — never leaves the developer's machine
- Azure credentials — encrypted at rest in Supabase Vault (AES-256)
- Audit logs — retained server-side for the lifetime of the account
- API authentication — OAuth 2.0 tokens or API keys, scoped to Qwick Cert