TX Text Control .NET for WPF

Certificate and Private Key Handling

Topic

A signed PDF says "the holder of this key approved this document". That statement is worth only as much as the protection of the private key. When a WPF application signs documents, it does so on the user's computer, with a key that is either the user's own or one your application brings along, and that choice decides who can sign in whose name. Planning the signing part of an application starts with three things: what TX Text Control expects, where keys can be kept and what each place means.

The code for loading certificates, choosing one and checking it before use is in Certificates in Digital Signatures.

How TX Text Control Uses the Certificate

TX Text Control takes the certificate as an X509Certificate2 with its private key, never as a file name or a password, and uses it while a PDF is saved; an optional time server adds a trusted timestamp. Your code therefore decides where the key comes from. How TX Text Control Takes the Certificate lists the constructors of DigitalSignature and the error an unusable certificate causes.

Choose Where the Private Key Is Kept

The signing samples in Text Control's articles take certificates either from .pfx files, which hold the certificate and the private key under a password, or from the Windows certificate store, which also lists certificates on smart cards, PIV cards and USB tokens. Who can sign follows from the choice:

Key kept inWho can signWhat to consider
A .pfx file installed with the applicationEvery user who can read the file and has its passwordThe application has to read the password from somewhere, which gives it to every user
A .pfx file on a protected share or in a databaseWhoever your application hands the file and password toA copy that was taken once stays usable
The certificate store of the current userThe Windows user who owns the certificateSignatures identify individual people
A smart card, PIV card or USB tokenThe holder of the deviceThe device must be connected while signing

When users sign documents in their own names, let them choose one of their certificates from the store of the current user; your installation then carries nothing that identifies a signer. The Windows dialog box for choosing a certificate also lists those on smart cards, and a certificate without a private key can't sign: Let the User Choose a Certificate opens the dialog box from a WPF window and accepts only certificates that have one.

Handle PFX Files With Care

A .pfx file is the usual form of a certificate that belongs to an organization, for example for sealing generated invoices:

  • Don't compile the password into the application. Every installed copy of the assembly would contain it. Ask for it, or read it from a place only authorized users reach.
  • Don't install the file for all users unless all of them may sign in the organization's name.
  • Reserve test certificates for tests. The samples of this documentation use certificate.pfx with the password 123, a self-signed certificate for development. Documents for outside recipients need a certificate from a certificate authority (CA) they trust, as What a Signing Certificate Needs explains.

What Makes a Signature Trustworthy

  • A key per signer. The signature names the holder of the key. When several people share one certificate, nobody can tell afterward which of them signed.
  • A valid certificate. Sign only with a certificate within its validity period, and add a trusted timestamp so that the signature can still be verified after the certificate expires, as Timestamp Configuration explains.
  • Encryption for confidential content. A signature makes changes visible but hides nothing; PDF Passwords and Permissions covers encryption.

Both sources of certificates are shown with code in the blog articles Signing PDF Documents with Smart Card Certificates in C# and Sign PDF Documents with an X.509 Certificate on a Hardware Device.

Next Steps