Certificate and Private Key Handling
Whoever holds the private key of a signing certificate can sign in the name of its owner. A digital signature proves who signed a PDF only as long as that key stays with its owner. In a Windows Forms application, signing happens on the user's computer, so where the key lives, who can read it and who knows its password are questions for the design of your application, not only for its deployment. What TX Text Control expects from a certificate, the places a key can be kept and what each of them means are covered below.
Loading certificates in code, letting the user choose one and checking it before signing are shown in Certificates in Digital Signatures.
What TX Text Control Does With a Certificate
A DigitalSignature takes an X509Certificate2 with its private key, and no file names or passwords, so where the certificate is loaded from is decided by your code. The certificate is used while the document is saved as PDF or PDF/A, as How TX Text Control Takes the Certificate describes. When the DigitalSignature names a time server, the signing computer contacts it, as Timestamp Configuration explains.
Where the Key Can Live
Text Control's articles sign with certificates from two sources: .pfx files, which contain the certificate and its private key protected by a password, and the Windows certificate store, where certificates on smart cards, PIV cards and USB tokens appear as well. Each has consequences for who can sign:
| Source | Who can sign | Keep in mind |
|---|---|---|
| A .pfx file that ships with the application | Everyone who can read the file and knows its password | The password has to be somewhere your application reads it, so every user of the application can sign with it |
| A .pfx file on a protected share or in a database | Everyone your application gives the file and the password to | Your application decides who gets them, and a copy stays usable after it was taken |
| The certificate store of the current user | The user the certificate belongs to | Each user signs with their own certificate, so a signature names a person |
| A smart card, PIV card or USB token | The person who holds the device | The device has to be connected to the computer that signs |
For an application whose users sign in their own names, the certificate store of the current user is the natural source: the user chooses one of their certificates in the Windows dialog box for selecting a certificate, which lists smart cards as well, and nothing that identifies the signer is installed with your application. Only certificates with a private key can sign. Let the User Choose a Certificate shows the dialog box and the code, which skips certificates without one.
Protect PFX Files and Their Passwords
When your application signs with a certificate of the organization, for example to seal invoices it generates, the key is typically a .pfx file:
- Keep the password out of the source code. A password in the code is part of every copy of the assembly. Ask for it when it's needed, or read it from a location that only authorized users can access.
- Keep the file out of the installation folder unless every user of the application may sign with it.
- Use test certificates only for tests. The samples of this documentation load certificate.pfx with the password
123, a self-signed certificate created for development. Recipients outside your organization need a certificate from a certificate authority they trust, as What a Signing Certificate Needs explains.
Keep Signatures Meaningful
- One certificate, one purpose. A signature says who holds the key, not who clicked the button. If several people share a certificate, the signature can't tell them apart.
- Encrypt as well when the content is confidential. A signature makes changes detectable but doesn't hide anything. PDF Passwords and Permissions describes the passwords that do.
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 show both sources with code.
Next Steps
- Certificates: load certificates from files and the certificate store and check them before signing.
- Signing PDF Documents: sign the document of the editor and generated documents.
- Timestamp Configuration: add a trusted signing time.
- Secure Application Deployment: what to leave out of the files you ship.