How Software Digital Signatures Work

A software digital signature helps answer two questions: has the signed content changed, and does the signature validate back to an identity or key you trust? It does this without treating the entire file as secret. Anyone may be able to download and read the software; the signature provides evidence about integrity and origin.

Code signing is the use of digital signatures for executables, installers, scripts, packages, updates, containers, or release records. Windows Authenticode, Apple Developer ID signing, signed Linux repository metadata, OpenPGP release signatures, and newer transparency-based systems apply the same broad idea through different trust models.

The signing process in plain language

A typical release-signing process has four parts:

1. A hash function calculates a fixed-length digest of the content.
2. The publisher's private signing key is used to create a signature over that digest and related metadata.
3. The signature, certificate or key identity, algorithm information, and often a timestamp travel with the file or release record.
4. A verifier calculates the digest again and uses the public key to check the signature.

If the content changed after signing, the newly calculated digest will not validate against the signature. If the mathematics succeeds but the key is not trusted for that software, integrity may be established without establishing the publisher you expected.

The private key must remain controlled by the signer. The corresponding public key can be distributed so others can verify signatures without gaining the ability to create them.

What a certificate adds

Many desktop signing systems use certificates. A code-signing certificate connects a public key with a named subject and is issued within a public key infrastructure. The certificate is itself signed by an issuing certificate authority, which may chain through intermediate certificates to a root trusted by the operating system.

Verification can therefore include several checks:

• The file's signature is mathematically valid.
• The certificate was valid for code signing under the applicable policy.
• The chain reaches a trusted root.
• The certificate was not revoked according to the available status information.
• The signed identity matches the publisher the user expected.
• A timestamp preserves evidence about when signing occurred.

Microsoft's SignTool documentation says its verification can determine whether the signing certificate was issued by a trusted authority and whether it was revoked. A successful chain is meaningful, but the displayed publisher name still needs human attention. Example Holdings LLC is not automatically the project you meant to install.

Why timestamps matter

Signing certificates expire. Without a trusted timestamp, a signature may stop validating after the certificate's validity period ends even though the file was legitimately signed earlier.

A cryptographic timestamp records evidence that a signature existed at a particular time. Microsoft recommends timestamping Authenticode signatures and explains that a timestamp can keep a signature verifiable after the signing certificate expires. The timestamp service countersigns information derived from the original signature rather than changing the program itself.

An expired certificate is therefore not the same as an invalid old signature. A verifier considers whether the signature was valid when it was timestamped, whether the timestamp validates, and whether relevant certificates or algorithms are still acceptable. A revoked certificate or a timestamp that cannot be trusted changes that analysis.

Windows Authenticode

Authenticode is the Windows code-signing system used for formats such as executable programs, libraries, installers, and catalog files. A signature may be embedded in a file or supplied through a signed catalog that lists file hashes.

For an ordinary graphical check, right-click the downloaded file, open Properties, and inspect the Digital Signatures tab if it appears. Select the signature, open its details, and confirm both the reported status and signer identity.

SignTool, included with the Windows SDK, offers more explicit verification:

signtool verify /pa /v example-installer.exe

The /pa option applies the default Authenticode verification policy, while /v shows detailed output. SignTool uses different policies for some driver and catalog scenarios, so advanced verification should follow the relevant Microsoft documentation rather than copying one command everywhere.

A missing Digital Signatures tab does not prove malware. Some legitimate open-source projects distribute unsigned Windows binaries. It means that this particular verification layer is unavailable, so source provenance, published hashes, package-repository trust, and other evidence carry more weight.

Apple signing and notarization

For software downloaded outside the Mac App Store, macOS Gatekeeper checks whether an app, plug-in, or installer package has an acceptable Developer ID signature and has not been altered. Current macOS versions also use notarization requirements and known-malware checks for ordinary distribution paths.

Apple distinguishes these concepts. Code signing connects code to the developer identity and detects changes to signed code. Notarization is an automated Apple service that scans submitted software and issues a ticket for software that passes its checks at that time. Neither is a promise that an app will always be safe or suitable.

Users should not remove quarantine attributes or disable Gatekeeper merely because a downloaded app triggers a warning. First confirm the project's current installation instructions and the identity of the file. A deliberate override is a security decision, not a routine installation step.

Signed package repositories

Linux and other package ecosystems often sign repository metadata rather than relying only on an embedded signature in each executable. The package manager validates signed indexes or manifests, then uses authenticated hashes in that metadata to validate individual packages.

This design can cover a whole repository and its updates, but the initial repository key and configuration still matter. Adding a signing key from an untrusted webpage gives that key authority over future package metadata. Follow the operating system or project's official repository setup instructions and review key changes rather than automatically importing replacements.

Standalone releases may use detached signatures such as .asc or .sig files. Verifying one requires both the downloaded artifact and the signature, plus an authenticated way to obtain or confirm the publisher's public key. A message saying Good signature is incomplete if the key itself has not been tied to the expected maintainer.

Checksums versus signatures

A checksum is a digest. A signature uses a private key to sign a digest and verification context. That extra identity layer changes what can be concluded.

The checksum guide shows how to calculate and compare file hashes. Checksums remain useful with signed software because they are easy to publish for formats without embedded-signature support and useful for mirrors.

What a valid signature does not prove

A valid signature does not certify that software is bug-free, private, ethical, maintained, or free from malicious behavior. It says something narrower about signed bytes and identity under a trust model.

Legitimate publishers can distribute vulnerable software. A build system can be compromised before signing. A signing key can be stolen. An unwanted program can be signed by its real publisher. A certificate authority validates according to its policy; it does not perform a complete security review of every future release.

This is why signatures belong inside a broader safe-download process. Confirm the release and source, keep system protections enabled, review permissions, and respond to credible warnings even when a signature is present.

Common verification failures

Different tools use different wording, but failures often fall into recognizable groups:

• Content changed: the calculated digest no longer matches the signed digest.
• Untrusted chain or key: the mathematics may work, but the verifier cannot establish trust in the signing identity.
• Revoked certificate: the certificate has been withdrawn by its issuer.
• Expired certificate without a valid timestamp: there is insufficient evidence that signing occurred during the valid period.
• Wrong policy or usage: the certificate or signature is not valid for the verification policy being applied.
• Missing intermediate certificate or unavailable status service: the verifier cannot complete a chain or status check.
• Unsupported algorithm: an old or weak signing method is no longer accepted.

Do not fix these by turning off verification. Check the publisher's official release notes, verify that you downloaded the intended artifact, update the operating system's trust store where appropriate, and ask the publisher for a corrected release if the failure persists.

Protecting the signing side

For maintainers, code signing moves risk toward the private key and release pipeline. A stolen key can let an attacker produce files that appear to come from the project until the key or certificate is revoked.

Good release practice limits access to signing keys, uses hardware-backed or isolated signing where practical, requires review before release, records what was signed, timestamps signatures, and has a documented revocation and replacement process. Build provenance and transparency logs can add evidence about how an artifact was created and whether a signing event was publicly recorded.

Sigstore is one example of a system combining short-lived signing identities with transparency logging for software artifacts. It does not remove the need to decide which identity, workflow, or repository you trust; it changes how that evidence is issued and audited.

How to read a signature result

Use this order:

1. Confirm that the tool says the signature is valid for the relevant policy.
2. Read the signer identity rather than accepting the word valid alone.
3. Compare that identity with the project's official publisher information.
4. Check timestamp and revocation information when available.
5. Confirm that the signed file is the version and platform artifact you intended.
6. Continue with source, reputation, permission, and behavior checks.

The best outcome is not simply “signed.” It is “the intended file, unchanged since signing, signed by the expected identity, validated through an appropriate trust path, with no contradictory warning.” That is strong evidence, while still leaving the final software decision to the user or organization.