OSSLSIGNCODE(1)
β¨ osslsigncode β¨
okay bestie, welcome to osslsigncode β your new main character. π
This is the manual page for osslsigncode, and she's a lot, but she's worth it.
π NAME π
osslsigncode β Authenticode signing, timestamping, extraction, attachment, removal, and verification tool π«Ά
πΈ SYNOPSIS πΈ
osslsigncode [--help] [--version]
osslsigncode sign [-certs file | -spc file | -pkcs12 file] [-key
file-or-URI] [-ac file] [-pass password | -readpass file | -askpass]
[-pkcs11module module] [-pkcs11cert URI] [-engine engine] [-provider
provider] [-login] [-engineCtrl command[:parameter]] [-h digest] [-n
description] [-i URL] [-jp low] [-comm] [-ph] [-t URL ... | -ts URL
...] [-TSA-certs file -TSA-key file-or-URI [-TSA-time unix-time]]
[-HTTPS-CAfile file] [-HTTPS-CRLfile file] [-time unix-time]
[-addUnauthenticatedBlob [-blobFile file]] [-nest] [-add-msi-dse]
[-verbose] [-pem] -in input -out output
osslsigncode extract-data [-pem] [-h digest] [-ph] [-add-msi-dse] -in
input -out output
osslsigncode add [-addUnauthenticatedBlob [-blobFile file]] [-t URL ...
| -ts URL ...] [-TSA-certs file -TSA-key file-or-URI [-TSA-time
unix-time]] [-HTTPS-CAfile file] [-HTTPS-CRLfile file] [-h digest]
[-index n] [-verbose] [-add-msi-dse] -in input -out output
osslsigncode attach-signature -sigin signature [-h digest] [-nest]
[-add-msi-dse] -in input -out output
osslsigncode extract-signature [-pem] -in input -out output
osslsigncode remove-signature -in input -out output
osslsigncode verify -in input [-c | -catalog catalog-file] [-CAfile
file] [-CRLfile file] [-HTTPS-CAfile file] [-HTTPS-CRLfile file]
[-TSA-CAfile file] [-TSA-CRLfile file] [-p proxy] [-index n]
[-ignore-timestamp] [-ignore-cdp] [-ignore-crl] [-time unix-time]
[-require-leaf-hash alg:hex] [-verbose]
likeβ¦ look at all those flags. she has range. π
π DESCRIPTION π
osslsigncode signs and verifies Microsoft Authenticode signatures on supported file formats. She can also extract data for detached signing, attach an externally produced signature, add timestamps or unauthenticated blobs to an existing signature, and remove an embedded signature. no cap. π₯
Supported input formats include PE files such as EXE, DLL, and SYS, plus CAB, CAT, MSI, APPX, and several script file types, including .ps1, .ps1xml, .psc1, .psd1, .psm1, .cdxml, .mof, and .js. she's versatile like that π
The program supports these common workflows:
- direct signing of an unsigned file
- detached signing via
extract-data,sign, andattach-signature - post-sign timestamping with
add - verification of embedded signatures or catalog signatures with
verify
bestie PSA: if no subcommand is given, sign is assumed. it's giving default behaviour β¨
π¦ FORMATS π¦
Support is not identical across all file formats. (iykyk π)
In particular, detached-signature workflows, nested signatures, catalog-based verification, and signature removal are format-dependent features. A command that is valid for one supported file type may be unsupported for another. no shade, that's just how it is.
CAT files are a special case. They are detached catalog containers for hashes of other files, not ordinary embedded-signature payloads. A CAT file is itself a PKCS#7 structure containing authenticated entries for one or more external files. In practice, the catalog signs file digests recorded in the catalog, rather than embedding a signature into each covered file. π
Because of this, CAT files behave differently from embedded-signature formats. They do not support attach-signature, remove-signature, extract-data, or nested signatures. periodt.
MSI files are also a special case. They support an extended signature mode controlled by -add-msi-dse. In this mode, the MSI signature covers file metadata as well as file content. Detached-signing workflows and any later re-signing or nesting operations must use a mode consistent with the MSI file's existing signature structure. β οΈ consistency is the vibe check here.
π COMMANDS π
π sign
Create a new Authenticode signature. π
This command can sign a normal unsigned file, or it can sign PKCS#7 data previously produced by extract-data.
π extract-data
Extract the PKCS#7 content to be signed later. This is used for detached signing workflows. β¨
π add
Add unauthenticated attributes to an existing signature β typically an Authenticode timestamp, an RFC 3161 timestamp, or an unauthenticated blob. π
With -index, the selected signature in a multi-signature file is updated.
π attach-signature
Attach a detached PKCS#7 signature to an input file.
With -nest, the new signature is attached as a nested signature instead of replacing the primary one, if the file format supports nested signatures. πͺ
π extract-signature
Extract the embedded PKCS#7 signature from a signed file. π΅οΈββοΈ
π remove-signature
Remove the embedded signature from a signed file. bye bye π
π verify
Verify an embedded signature or a catalog signature.
Verification may include digest consistency, certificate chain validation, certificate revocation checking, timestamp validation, and optional checking of the signer's leaf certificate hash. π
When verifying that a file is covered by a catalog, use verify -catalog catalog.cat -in file. Verifying the CAT file by itself validates the catalog signature; verifying with -catalog checks whether the specified input file is covered by that catalog. slay. π
β¨ OPTIONS β¨
okay bestie so here's the tea: some options only exist in certain builds or on certain OpenSSL versions. Like, not every build is gonna have every vibe. Specifically: -askpass is build-dependent, -provider and -nolegacy need OpenSSL 3, and anything engine-related depends on whether the build even supports engines. So if something's giving "unknown option" energy, that might just be your build. π
πΈ General options πΈ
--helpβ shows the help text. And if you tack it onto a subcommand, you get the help for that subcommand specifically. so helpful, so considerate.-v,--versionβ spills the version info. π-infile β the input file. the one you're working on.-outfile β the output file. required for every command exceptverify, so don't forget it.-verboseβ turns up the detail dial and gives you way more diagnostic output. for when you need to see everything.
π Signing material π
-pkcs12file β reads your signing certificate AND your private key straight out of a PKCS#12 container. two birds, one adorable little bundle.-certs,-spcfile β reads the signing certificate chain. and yeah,-spcis the old-school alias, still accepted, no cap. π-keyfile-or-URI β reads the private key. this can be a file, or a store URI, or a PKCS#11 URI. flexible queen.-acfile β adds extra certificates into the signature block.-passpassword β the password or PIN for your key, token, or PKCS#12 container.-readpassfile β reads the password or PIN out of file. and if you set the file to-, it reads from standard input instead. kinda iconic.-askpassβ prompts you for the password interactively. very "type it in yourself" of it.
π§ PKCS#11, engines, and providers π§
-pkcs11modulemodule β the path to a PKCS#11 module.-pkcs11certURI β a PKCS#11 URI that points at the certificate object.-providerprovider β loads an OpenSSL 3 provider. this is THE preferred, modern interface for provider-based PKCS#11 use, so if you're on OpenSSL 3, this is your moment. β¨-engine,-pkcs11engineengine β an OpenSSL engine identifier, or a path to a dynamic engine module. this interface is kept around purely for compatibility with builds and deployments that are still out here supporting engines. it's giving "legacy but loyal".-loginβ forces a login to the token for engine-based PKCS#11 use.-engineCtrlcommand[:parameter] β passes a control command to whichever engine you selected.-nolegacyβ on OpenSSL 3 builds, stops it from automatically loading the legacy provider. like, don't come with that legacy energy.
π¦ Signature contents and digest control π¦
-hmd5 | sha1 | sha2 | sha256 | sha384 | sha512 β picks the digest algorithm. the default issha256. and fyi,sha2andsha256are literally the same thing, two names one queen. π-ndescription β the description of the signed content.-iURL β an informational URL tied to the signed content.-commβ uses the Microsoft Commercial Code Signing purpose instead of the default individual purpose.-jplow β adds the Java CAB permission attribute. and rnlowis the only value supported, so don't get creative. π-phβ generates page hashes for executable files.-add-msi-dseβ for MSI files, this turns on theMsiDigitalSignatureExsigning mode. in this mode the signature covers MSI metadata as well as file content. and the metadata portion includes stream names, sizes, and selected timestamps in the MSI structure. ok so this one actually matters, listen up: this option changes the MSI signature format, so you have to use it consistently in any detached-signing workflow involvingextract-data,sign,attach-signature, oradd.
for a newly signed MSI, this mode is generally preferred, because it extends signing coverage beyond just file content alone. but for an already signed MSI, the mode you choose has to match the file's existing signature structure. and here's the warning bestie: switching between basic MSI signing and MsiDigitalSignatureEx during re-signing or nested-signature operations can invalidate the existing signature. so be careful, we do not want that. π
-pemβ writes PKCS#7 output in PEM format instead of DER.
π Timestamping and network options π
so these timestamping modes are mutually exclusive within a single sign or add invocation. like, pick one vibe, you cannot have all three at once:
- Authenticode timestamping with
-t - RFC 3161 timestamping with
-ts - built-in RFC 3161 timestamp generation with
-TSA-certsand-TSA-key -tURL adds an Authenticode timestamp from the URL you specify. and you can repeat it if you want more than one. π₯-tsURL adds an RFC 3161 timestamp from the specified URL. also repeatable, go off.-pproxy the proxy used for timestamp or CRL retrieval.-noverifypeerskips verifying the TLS certificate of the remote timestamp service. (do with that what you will.)-HTTPS-CAfilefile a PEM bundle used to verify the HTTPS peers thatosslsigncodecontacts.-HTTPS-CRLfilefile a PEM CRL file used while verifying HTTPS peers.-TSA-certsfile a PEM certificate chain, for locally generated RFC 3161 timestamps.-TSA-keyfile-or-URI the private key for locally generated RFC 3161 timestamps.-TSA-timeunix-time the timestamp time for locally generated RFC 3161 responses.
π Nested signatures and indexed operations π
-nestβ adds a nested signature instead of replacing the primary one. we're layering, not swapping. β¨-indexn β selects a signature by index, foraddorverify. index0is the primary signature, iykyk.
π Unauthenticated blob options π
-addUnauthenticatedBlobβ adds an unauthenticated blob to the signature.-blobFilefile β reads the blob contents from file. and if you don't give it one, a placeholder blob gets created instead. cute little default.
πΈ Verification options πΈ
-c,-catalogfile β verifies the input file against the catalog file you point at.-CAfilefile β a PEM bundle of trusted CA certificates, used for signer validation.-CRLfilefile β a PEM file full of CRLs, used for signer validation.-TSA-CAfile,-untrustedfile β a PEM bundle of trusted CA certificates, this time for timestamp validation.-TSA-CRLfile,-CRLuntrustedfile β a PEM file of CRLs, for timestamp validation.-time,-stunix-time β the verification time. and heads up: if a valid timestamp is present and used, chain validation is normally done at the timestamp time instead.-ignore-timestampβ skips verification of the timestamp signature entirely.-ignore-cdpβ does not fetch CRLs from CRL Distribution Points.-ignore-crlβ disables CRL retrieval AND CRL validation. both, gone.-require-leaf-hashalg:hex β requires the signer's leaf certificate to hash to the value you specified. the hash gets computed over the DER encoding of the leaf certificate, so it's the real deal.
β EXIT STATUS β
0β success. π- non-zero β failure. π
π DIAGNOSTICS π
here are the common reasons things go sideways, so you can go "oh THAT's what it was":
- missing CA trust bundle on Unix-like systems,
verifyexpects a readable CA bundle, either from-CAfileor from a detected system default. no bundle, no service. - detached-signing mismatch
extract-data,sign, andattach-signaturehave to use compatible digest-affecting options such as-h, and where relevant-phand-add-msi-dse. they have to match up, fr fr. - unsupported format feature some file formats just don't support every subcommand or every signature mode. it's not you, it's the format.
- missing TSA trust chain timestamp verification may fail unless you supply the appropriate TSA trust anchors with
-TSA-CAfile, and where needed-TSA-CRLfile. - conflicting timestamp modes
-t,-ts, and built-in TSA signing cannot be combined in one command. one at a time, bestie. - MSI signature mode mismatch re-signing or nesting an MSI signature has to be consistent with whether the file already uses
MsiDigitalSignatureEx. mixing modes may invalidate the existing signature. we've said it once and we'll say it again.
πΏ ENVIRONMENT πΏ
HTTP_PROXY,http_proxyβ the default proxy for HTTP access, if-pisn't given.HTTPS_PROXY,https_proxyβ the default proxy for HTTPS access, if-pisn't given.OPENSSL_ENGINESβ may help OpenSSL find engine modules. a little assist. π«Ά
π FILES π
on Unix-like systems, osslsigncode goes looking through common CA bundle locations for its default -CAfile, including these:
/etc/ssl/certs/ca-certificates.crt/etc/pki/tls/certs/ca-bundle.crt/usr/share/ssl/certs/ca-bundle.crt/usr/local/share/certs/ca-root-nss.crt/etc/ssl/cert.pem
and if there's no readable CA bundle anywhere to be found, verify may need you to hand it an explicit -CAfile. periodt.
π NOTES π
use extract-data when you need to create a new detached signature object. use extract-signature when you need to copy an existing embedded PKCS#7 signature out of a file. two different jobs, don't mix them up. π
for safer secret handling, prefer -readpass or -askpass over -pass. protect your passwords, they deserve it.
anything you add with -addUnauthenticatedBlob is not protected by the signature and must not be treated as trusted. like, it's called unauthenticated for a reason bestie. π
for new MSI signatures, -add-msi-dse is generally preferred because it extends signing coverage to MSI metadata as well as file content. but it's format-affecting rather than cosmetic, so existing signed MSI files should only be re-signed in a mode consistent with their current signature structure. remember, consistency is the whole thing here.
and one more: output files are not overwritten. so if you thought it would just hoop over your file, it will not. π
π EXAMPLES π
Sign and verify a file
osslsigncode sign \
-pkcs12 signer.p12 \
-readpass p12-pass.txt \
-n "Example Application" \
-i "https://example.com/" \
-ts "https://tsa.example.net/" \
-in app.exe \
-out app-signed.exe
osslsigncode verify \
-CAfile ca-bundle.pem \
-TSA-CAfile tsa-ca-bundle.pem \
-in app-signed.exe
Detached signing workflow
osslsigncode extract-data \
-h sha384 \
-ph \
-in app.exe \
-out app-data.der
osslsigncode sign \
-pkcs12 signer.p12 \
-readpass p12-pass.txt \
-h sha384 \
-in app-data.der \
-out app-sig.der
osslsigncode attach-signature \
-h sha384 \
-sigin app-sig.der \
-in app.exe \
-out app-signed.exe
osslsigncode verify \
-CAfile ca-bundle.pem \
-in app-signed.exe
Sign a new MSI with extended MSI metadata coverage
osslsigncode sign \
-pkcs12 signer.p12 \
-readpass p12-pass.txt \
-add-msi-dse \
-in installer.msi \
-out installer-signed.msi
Use a PKCS#11 provider
osslsigncode sign \
-provider /path/to/pkcs11prov.so \
-pkcs11module /path/to/opensc-pkcs11.so \
-pkcs11cert 'pkcs11:token=my-token;object=cert' \
-key 'pkcs11:token=my-token;object=key' \
-readpass pin.txt \
-in app.exe \
-out app-signed.exe
Add a timestamp to an already signed file
osslsigncode add \
-ts "https://tsa.example.net/" \
-in app-signed.exe \
-out app-signed-ts.exe
Verify that a file is covered by a catalog
osslsigncode verify \
-catalog drivers.cat \
-CAfile ca-bundle.pem \
-CRLfile ca-crl.pem \
-in driver.sys
π REPORTING BUGS π
found a bug? suspected something shady? report it through the project issue tracker:
https://github.com/mtrojnar/osslsigncode/issues
π AUTHORS π
Okay so bestie, this whole thing has lore, and the lore is stacked:
- Originally written by Per Allansson. The founding father, the blueprint, the first ever commit energy. π«Ά
- Maintained and extended by MichaΕ Trojnara. That's the person keeping the lights on and the features shipping. Main character of the maintenance arc, fr fr. π
- Major contributions by MaΕgorzata OlszΓ³wka. Major. Not minor. Not "typo fixes." Major. Ate and left absolutely no crumbs. π β¨
- Additional contributions by other project contributors. Shoutout to the group chat of devs who popped in, dropped a patch, and ghosted with grace. You're all iconic and we see you. π¦
ngl, open source is just a bunch of people being obsessed with the same problem in public, and this list is proof. π
π SEE ALSO π
- OpenSSL Library
https://openssl-library.org/
Like, this page doesn't exist in a vacuum, babe. When you want the deep-down crypto lore β the algorithms, the certificate machinery, the stuff happening under the hood while osslsigncode is out here doing the signing β that's where you go. Go read it. It's giving required reading. ππ§
And that's the whole page, bestie!! π You made it to the very bottom, which honestly deserves a little round of applause. π
The footer down here is just osslsigncode() β no version number, no date, nothing extra, just the tool signing off with its own name like the icon it is. ππ
Now go sign something. Slay. ππ₯
π¦ where this page comes from
- ubuntu stonking: osslsigncode 2.14-1 Β· GPL-3.0+~OpenSSL
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms