Timestamp

Digital signatures prove who signed a PDF and whether the document has been modified after signing. But there is one important question a digital signature alone cannot answer:

When was the document signed?

That seemingly simple question becomes critical years later.

If a certificate expires, is renewed, or even revoked after the document was signed, how can a validator determine that the signature was still valid at the moment the signature was created?

This is exactly why enterprise document workflows use RFC 3161 timestamp servers .

In this article, we'll explore how timestamping works, why it is essential for long-term PDF validation, and how to add trusted timestamps to PDFs using TX Text Control and modern .NET.

A Digital Signature Is Only Part of the Story

When you digitally sign a PDF, your application performs several steps:

Calculate a cryptographic hash of the document. Encrypt that hash using the private key stored in your PFX certificate. Embed the resulting signature together with the signing certificate into the PDF.

The signature proves two things:

the document has not changed the signer possessed the private key

What it doesn't prove is when that signature was created.

Without trusted time information, a validator has no independent way to determine whether the certificate was still valid at signing time.

The Certificate Problem

Imagine this timeline of events:

The digital signature itself is mathematically correct. Cryptographic verification proves that the document has not been altered since it was signed and that the signature was created using the corresponding private key.

However, years may have passed since the document was signed. The signing certificate may have expired, been renewed, or been revoked. When someone opens the document in Adobe Acrobat five or ten years later, the validator must answer an important question:

Was the certificate valid at the exact moment the signature was created?

Without trusted proof of the signing time, there is no definitive way to answer that question. The validator only knows the certificate's current status, not its status when the document was signed.

For instance, if a document were signed in February 2026, but the certificate expired in January 2027, opening the document in 2032 would provide no evidence that the certificate was valid in February 2026. While the cryptographic signature remains intact, the timing of the signature cannot be proven.

This is exactly why trusted timestamping exists. By obtaining an RFC 3161 timestamp from an independent Time-Stamping Authority (TSA) when the document is signed, the signature becomes associated with a trusted Coordinated Universal Time (UTC) time. The timestamp serves as cryptographic evidence that the signature existed while the signing certificate was valid. This enables PDF validators to trust the signature long after the certificate has expired.

What Is an RFC 3161 Timestamp Server?

A timestamp server that adheres to RFC 3161, also known as a Time-Stamping Authority (TSA), does not sign your PDF document. Your document has already been digitally signed using your certificate and private key before the timestamp server becomes involved.

Instead, the timestamp server receives a cryptographic hash of the digital signature, not the PDF itself. Since a hash is a mathematical fingerprint that cannot be reversed, the TSA cannot reconstruct or view the document's contents. This makes the timestamping process both secure and privacy-friendly.

The TSA combines this hash with the current trusted UTC time and digitally signs the result using its own certificate. The returned timestamp token serves as cryptographic proof that the signature existed at the recorded date and time.

You can think of the TSA as a digital notary. Rather than approving or signing the document, the TSA certifies that a particular digital signature existed at a specific moment in time. In effect, the timestamp authority is stating:

"I confirm this exact signature already existed on August 4th, 2026 at 08:17:53 UTC."

This statement is digitally signed by a trusted timestamp authority. Therefore, anyone validating the PDF years later can verify the timestamp's authenticity and the exact time the signature was created. Even if the original signing certificate has expired or been revoked, the timestamp proves that the certificate was valid when the document was signed.

What Actually Happens?

The communication with the timestamp server follows RFC 3161.

An important aspect of RFC 3161 timestamping is that the PDF document itself is never sent to the timestamp server. Instead, the application generates a cryptographic hash of the digital signature and sends this small, fixed-size fingerprint, called a "cryptographic hash," to the Time Stamping Authority (TSA).

A cryptographic hash is a mathematical representation of the signature that cannot be reversed. It uniquely identifies the signed data but cannot be used to reconstruct the original document or reveal its contents. Consequently, the TSA never has access to the PDF, its contents, or any confidential information stored within it.

The TSA simply signs the received hash together with the current trusted UTC time and returns the resulting timestamp token. The token is embedded in the PDF as part of the digital signature.

The PDF never leaves your system. Only a cryptographic fingerprint of the digital signature is sent to the Time Stamping Authority, allowing it to certify the signing time without ever accessing the document's contents.

Since only a cryptographic fingerprint is exchanged, RFC 3161 timestamping is secure and respects your privacy. Sensitive business documents remain entirely within your infrastructure while the trusted timestamp authority only certifies the digital signature's existence at a specific point in time.

Why Is This Important?

Years later, a PDF validator performs the following checks:

Is the digital signature mathematically correct? Was the certificate trusted? Was the certificate valid at the timestamp? Is the timestamp itself trusted? Has the document changed since signing?

If all validation checks succeed, the PDF validator can reliably conclude that the document was signed while the signing certificate was still valid. The trusted RFC 3161 timestamp provides independent, cryptographic evidence of the exact signing time. This allows the validator to verify the certificate's status at the time of signing rather than relying on its current status.

This distinction is essential for long-term document validation because certificates naturally expire and may be revoked after they have been used to sign documents. Certificates naturally expire and may be revoked after being used to sign documents. As long as the signature was created before the certificate expired and a trusted timestamp is present, the signature can be considered valid years later.

Without a trusted timestamp, however, this proof is missing. Once a signing certificate expires, PDF validators, such as Adobe Acrobat, can no longer determine if the certificate was valid when the signature was created. Consequently, they often display warnings or indicate that the long-term validity of the signature cannot be verified, even if the document itself has not been modified.

PAdES-B vs. PAdES-T

It is a common misconception that all digitally signed PDFs provide the same level of long-term trust. In reality, the level of assurance depends on the PAdES profile used to sign the document.

A PAdES-B (Basic) signature includes the digital signature, the signer's certificate, and the associated certificate chain. This information is sufficient to verify the document's authenticity and integrity immediately after signing. However, the signature's long-term validity still depends on the status of the signing certificate. Once the certificate expires or is revoked, a validator may be unable to determine whether it was valid when the document was signed.

A PAdES-T (Timestamp) signature is based on the PAdES-B profile and adds a trusted RFC 3161 timestamp. This timestamp provides independent cryptographic proof of the exact time at which the digital signature existed. During validation, PDF viewers can verify the document's integrity and the signature's authenticity, as well as confirm that the signing certificate was valid at the recorded timestamp.

Though the difference between the two profiles is technically just the addition of a timestamp token, the impact is significant. A trusted timestamp transforms a basic digital signature into one that supports reliable long-term validation. This allows signed PDF documents to remain trustworthy, even years after the signing certificate has expired.

Adding a Timestamp with TX Text Control

Using TX Text Control, timestamping is built directly into the PDF signing process.

using System.Security.Cryptography.X509Certificates; using TXTextControl;

using var tx = new ServerTextControl(); tx.Create();

tx.Text = "Hello PDF!";

var certificate = X509CertificateLoader.LoadPkcs12FromFile( "certificate.pfx", "password", X509KeyStorageFlags.Exportable);

var saveSettings = new SaveSettings { DigitalSignature = new DigitalSignature( certificate, "http://timestamp.digicert.com") };

tx.Save( "signed.pdf", StreamType.AdobePDF, saveSettings); The second parameter of the &#9584; TX Text Control .NET Server &#9584; TXTextControl Namespace &#9584; DigitalSignature Class &#9584; DigitalSignature Constructor Initializes a new instance of the DigitalSignature class. " data-tippy-interactive="true" data-tippy-placement="bottom" data-tooltip-width="wide"

>Digital Signature constructor specifies the RFC 3161 timestamp server. During PDF creation, TX Text Control automatically requests a trusted timestamp and embeds the returned timestamp token into the PDF.

The result is a PDF that contains both the digital signature and the trusted signing time.

Public Timestamp Servers

Several certificate authorities provide publicly accessible RFC 3161 timestamp services, including:

DigiCert GlobalSign Entrust SSL.com

Many organizations also operate their own internal timestamp authorities for corporate signing workflows.

Best Practices

When implementing digital signatures in production environments, it is important to follow established best practices. This ensures that signed documents remain trustworthy and verifiable for many years. Use a trusted RFC 3161 timestamp server to provide independent proof of the signing time and sign documents with certificates issued by a reputable certificate authority (CA). Including the complete certificate chain in the PDF enables validators to establish a trusted certification path without relying on external information.

After the signature has been applied, signed documents should be archived without modification, as even the slightest change invalidates the cryptographic signature. Additionally, organizations should validate incoming signatures as part of their document ingestion process to detect invalid, expired, or tampered documents before they enter business workflows.

Learn more

Learn how to validate digital signatures and the integrity of PDF documents using the PDF Validation component from TX Text Control in C# .NET. Ensure the authenticity and compliance of your documents.

Validate Digital Signatures and the Integrity of PDF Documents in C# .NET

Although requesting a trusted timestamp adds only a fraction of a second to the signing process, it provides substantial benefits. By proving exactly when a document was signed, timestamping improves the long-term reliability, interoperability, and legal evidential value of digitally signed PDF documents significantly.

Conclusion

A digital signature answers a fundamental question: Who signed this document? A trusted RFC 3161 timestamp provides the answer to another important question: When was it signed? While these concepts are closely related, they serve different purposes. A digital signature protects the document's authenticity and integrity, while a trusted timestamp provides independent evidence of the exact moment the signature was created.

This distinction becomes increasingly important over time. Certificates naturally expire and may be renewed or revoked after a document has been signed. Without a trusted timestamp, proving that the signing certificate was valid when the signature was applied can become difficult—or even impossible. However, by including an RFC 3161 timestamp, PDF validators can verify the signature years later, even after the original signing certificate has expired.

TX Text Control simplifies this process by integrating timestamping directly into the PDF signing workflow. During PDF generation, developers can specify the address of a trusted timestamp server to create digitally signed documents that comply with the PAdES-T profile and support reliable long-term validation with minimal additional effort.

TX Text Control .NET Server

DS Server

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

Blog

Core Technologies

Blog

Authors

Latest Posts

Support Resources

Documentation

Support

Getting Started

Other Resources

About Us

Industry events

Company

Contact

Newsletter

Legal

Sign in

Create account

Text Control Account

Timestamp

Post tagged with Timestamp in 2026

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

​

Latest Posts

​

Support

Getting Started

​

Other Resources

Company

Contact

Newsletter

Legal

Text Control Account

​

​

Timestamp

Post tagged with Timestamp in 2026 ​

August 2026

Post tagged with Timestamp in 2026