Using Code signing certs, for general filetype signing, possible?

In order to be able to digitally sign (virtually) any filetype, with a key or certificate that can be verified by a CA, would it be possible to use Code Signing certificates, of some kind, in any way?

Filetypes I have in mind, are everyday filetypes, zip, mp4, mp3, docx, wav, txt, pdf etc.

Looking for some kind of a solution to sign 'everyday' filetypes, with a sign that could be verified by a CA. And not transfer protocol certs, but just plain local digital signing.


1 Like

LE doesn't offer code signing certs, so this is likely not the best place to look for practical uses for them.

I would guess that if the code signing process alters the contents, it would have to change the extension to one that conveys the new use. Think zip file that may contain any other type of file and the zip container is what is being signed.
[but that is just my guess - again, there is little experience in this forum with code signing]


Signing arbitrary files is... Complicated.

1 Like

I think this would be a good use of PGP, although I wonder if you could hash the files and sign the hash with a CA issued certificate?

1 Like

One thing that Mozilla was exploring was putting file hashes into DNS domains, in order to create a public record (via the Certificate Transparency system) of the existence of software releases.

I think this is pretty clever.

I'm sure people will be aware that there is currently no significant software ecosystem to consume / validate / display those, though. (Maybe there will be in the future!)

Edit: I believe this is a research prototype that Mozilla hasn't continued actively using, but you can read about it at Security/Binary Transparency - MozillaWiki


There's the technology already, in the EU you can get your digital signature linked to your legal identity.

I'm not sure what PKI topology we're using, bit I'm quite sure you can only certify legal identities.

OpenPGP/gnupg is already used to sign software releases, for example the Debian repositories distribute gpg-signed files over unencrypted http.

1 Like

Digital signatures are made with the private key, and I haven't found a CA which will certify a public PGP key - yet.
PGP signatures includes SHA256 hashes already, but they don't facilitate "true" attribution - without a CA verification.
If a 'man-in-the-middle' has signed the files (as in: deleted my signatures and signed the files himself), and also sends a public key (source unknown), the receiver may trust it is all authentic as long as the public key works. Not acceptable.
Only solution I see: have my public key certified as belonging to my physical person, by an authority, for attribution. No CA seems to offer that. Definition of a clusterf**k.

Edit: .. or, did you mean signing the hash-file with a non-PGP certification method? That ... might be worth looking into. I know too little to imagine an immediate implementation of it. I still imagine it must be encryption based, to prevent a MITM to simply copy and reuse the signature?

I don't believe there is such a CA. There are for S/MIME, but that brings its own issues. But if you distribute your PGP key on a website you control, for which you've obtained a certificate that verifies your identity (EV or OV, if you feel it matters), the CA is validating you, and you're validating the PGP key. That should address what you're wanting to do.


Yeah I first thought PGP. Then got to thinking maybe just hashing and finding a way to sign the hash with a CA issued x.509 certificate.

Sounds interesting at first glance. My knowhow doesn't reach far enough to be able to see how possible it is. I have been told x.509 and PGP is mostly applied for e-mail type usage. And a hash-file is usually a simple TXT-file. Would there be some form of software that supports signing text-files using x.509 certificate?

Yes, but you cannot use Let's Encrypt certificates for that. They would get revoked for misuse.

(CA/B BR, § "Reasons for Revoking a Subscriber Certificate")

1 Like

I think you're going to be hard pressed to find a solution for signing generic file types that have no native concept of signatures that is also able to be reliably verified by a random third-party. The closest you're going to get is some sort of container format that does support signing that you can embed the files to be signed within.

That said, if your flexible with the "verified by a CA" requirement, Keybase has what they call Keybase Filesystem which transparently signs everything you put in it. For example, I just uploaded a publicly accessible text file.


I'm unclear on why the root programs would consider this to be misuse. Is it just because there is no EKU on the certificate that endorses its use for that purpose?

My intuition is that the EKUs are statements addressed to the relying party about purposes for which the CA endorses the certificate, rather than statements to the subscriber about how the certificate may be used. So, in my interpretation, Let's Encrypt is not encouraging relying parties to accept these signatures for some other application, but the subscriber isn't necessarily in breach of a subscriber agreement (and the CA isn't necessarily in breach of the BRs) for attempting or allowing it.

While searching for information about this, I found

indicating that Digicert is working on making this use case official. (It's interesting that that hasn't already happened in the past.)

It looks like the current version is

I don't know whether Let's Encrypt would be interested in supporting this if it is eventually standardized (or, for that matter, whether root programs or other entities would create a new set of rules for what kind of validation should be done before issuing publicly-trusted certificates for this purpose).


I mean, there's an entire x509 extension to allow signing webpages before they're given to a CDN or distributed offline: Signed HTTP Exchanges - Chrome Developers

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.