How to Code-Sign a PyInstaller EXE (Windows, and from Linux CI)

A code signature binds your executable to a publisher identity verified by a certificate authority, and proves the file hasn't been altered since you signed it. Concretely, that:

• Clears most antivirus false positives — a signed binary from a known publisher is far less likely to trip heuristic/ML detection than an anonymous unsigned one.
• Starts SmartScreen reputation — the download/run warning fades as your signed app accumulates installs under the same identity.
• Shows a real publisher in the UAC prompt and file Properties instead of "Unknown publisher."

You can't self-sign your way to trust: Windows only trusts a certificate chained to a CA it already trusts. Your choices:

• OV (Organization Validation) — the standard, cheapest CA option. The CA verifies your business exists. Good enough to clear AV flags and build reputation.
• EV (Extended Validation) — stricter identity checks, historically instant SmartScreen trust (no longer guaranteed). More expensive.
• Microsoft Trusted Signing (formerly Azure Code Signing) — a low-cost, cloud-based signing service; no physical token to manage, and it integrates cleanly with CI. Often the easiest modern route for individuals and small teams.

signtool ships with the Windows SDK. With your certificate installed (from its token/store), sign and timestamp in one command:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a myapp.exe

:: verify it afterwards
signtool verify /pa /v myapp.exe

/fd SHA256 sets the file digest, /tr + /td add an RFC3161 timestamp (see below), and /a auto-selects the best signing cert in your store. For a Trusted Signing setup you use the Azure.CodeSigning dlib instead of a local cert; Microsoft's docs and GitHub Action wire it up.

You don't need Windows to sign a Windows .exe. osslsigncode does Authenticode signing on Linux and macOS, which is what you want in a GitHub Actions or Docker pipeline. Here's the real flow I ran against a PyInstaller build. First, for the demo, a self-signed code-signing cert (in production you'd point at your CA cert or token instead):

openssl req -x509 -newkey rsa:3072 -keyout key.pem -out cert.pem -days 365 -nodes \
  -subj "/CN=Acme Ltd/O=Acme Ltd/C=US" \
  -addext "keyUsage=digitalSignature" \
  -addext "extendedKeyUsage=codeSigning"

The unsigned PyInstaller .exe has no signature at all:

$ osslsigncode verify myapp.exe
No signature found
Unable to extract existing signature
Failed

Now sign it, adding a timestamp from a trusted authority:

osslsigncode sign -certs cert.pem -key key.pem \
  -n "MyApp CLI tool" -i "https://acme.example" \
  -h sha256 -ts http://timestamp.digicert.com \
  -in myapp.exe -out myapp-signed.exe

Connecting to http://timestamp.digicert.com
Succeeded

And verifying the signed file shows the embedded Authenticode signature — with the digest of the file matching, which proves the executable content is intact and covered by the signature:

$ osslsigncode verify myapp-signed.exe
Signature Index: 0  (Primary Signature)
Message digest algorithm  : SHA256
Current message digest    : DE8303C77214A7912650D64B77A96711929A16EED382BA84...
Calculated message digest : DE8303C77214A7912650D64B77A96711929A16EED382BA84...
    Subject: /CN=Acme Ltd/O=Acme Ltd/C=US
    Issuer : /CN=Acme Ltd/O=Acme Ltd/C=US
Countersignatures:
    Timestamp time: Sep  1 09:59:58 2026 GMT
    Issuer: /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 TimeStamping ...

The signature added about 8 KB to the file (5,998,560 -> 6,006,592 bytes) and left the program itself untouched. With a self-signed cert like this, Subject equals Issuer and Windows won't trust the chain — the mechanism works, but real-world trust needs a CA cert (swap -certs/-key for -pkcs12 yourcert.pfx). The timestamp, though, is real and from DigiCert.

A code-signing certificate expires (typically in 1–3 years), but software you shipped should keep working long after. An RFC3161 timestamp — the -ts / /tr flag above — records *when* you signed, countersigned by a timestamp authority. So even after your cert expires, Windows sees "this was validly signed on a date the cert was active" and keeps trusting it. Sign without a timestamp and every signature silently dies with the certificate.

The clean way to sign is in CI, right after the build, so the binary is never touched by a developer machine. Store the certificate (base64 of the .pfx) and its password as encrypted repository secrets, then decode and sign in the workflow with osslsigncode:

- name: Sign the executable
  env:
    CERT_B64: ${{ secrets.CODESIGN_PFX_B64 }}
    CERT_PW:  ${{ secrets.CODESIGN_PFX_PASSWORD }}
  run: |
    echo "$CERT_B64" | base64 -d > cert.pfx
    osslsigncode sign -pkcs12 cert.pfx -pass "$CERT_PW" \
      -h sha256 -ts http://timestamp.digicert.com \
      -in dist/myapp.exe -out dist/myapp-signed.exe
    rm -f cert.pfx

If you use Microsoft Trusted Signing, there's an official GitHub Action that signs with the cloud key instead of a stored .pfx — no secret to leak. Either way, sign the artifact the build job produced, then attach the *signed* file to your release.

Set expectations: signing removes the malware-style flag and makes the publisher known, but a brand-new signed app can still show a SmartScreen prompt until it earns reputation through downloads. This is the biggest change from a few years ago — EV certificates used to grant instant SmartScreen trust, and no longer reliably do. Reputation now accrues to your consistent publisher identity over install volume, for both OV and EV. So sign every release with the *same* certificate, ship consistently, and the warnings fade. For the false-positive side of this, see PyInstaller EXE flagged as a virus.

Signing is the last step of a good release, not a substitute for the earlier ones. Build a clean, metadata-carrying executable first — our free Python-to-EXE builder produces a real PyInstaller .exe with embedded version metadata plus a GitHub Actions workflow you can drop this signing step into. Build it reproducibly, sign it in CI, timestamp it, and ship the signed artifact.