Some test text!
When providing trusted certificate(s) through the
VerificationOptions.AddTrustedCertificate method, ensure that it is
the root certificate corresponding to the chain used by the timestamp authority to sign the timestamp token.
Check your Certificate Authority's website for a list of root certificates they have publicly available, and choose the root certificate corresponding to the set of certificates that have been signed by that root certificate for your usage.
To add a DocTimeStamp signature:
doc = PDFDoc.new(in_docpath); doctimestamp_signature_field = doc.CreateDigitalSignatureField(); tst_config = TimestampingConfiguration.new("URL_to_timestamp_authority"); opts = VerificationOptions.new(VerificationOptions::E_compatibility_and_archiving); # It is necessary to add to the VerificationOptions a trusted root certificate corresponding to # the chain used by the timestamp authority to sign the timestamp token, in order for the timestamp # response to be verifiable during DocTimeStamp signing. opts.AddTrustedCertificate(in_trusted_cert_path); # By default, we only check online for revocation of certificates using the newer and lighter # OCSP protocol as opposed to CRL, due to lower resource usage and greater reliability. However, # it may be necessary to enable online CRL revocation checking in order to verify some timestamps # (i.e. those that do not have an OCSP responder URL for all non-trusted certificates). opts.EnableOnlineCRLRevocationChecking(true); widgetAnnot = SignatureWidget.Create(doc, Rect.new(0.0, 100.0, 200.0, 150.0), doctimestamp_signature_field); doc.GetPage(1).AnnotPushBack(widgetAnnot); # (OPTIONAL) Add an appearance to the signature field. img = Image.Create(doc.GetSDFDoc(), in_appearance_img_path); widgetAnnot.CreateSignatureAppearance(img); puts('Testing timestamping configuration.'); config_result = tst_config.TestConfiguration(opts); if (config_result.GetStatus()) puts('Success: timestamping configuration usable. Attempting to timestamp.'); else # Print details of timestamping failure. puts(config_result.GetString()); if config_result.HasResponseVerificationResult() tst_result = config_result.GetResponseVerificationResult(); puts('CMS digest status: '+ tst_result.GetCMSDigestStatusAsString()); puts('Message digest status: ' + tst_result.GetMessageImprintDigestStatusAsString()); puts('Trust status: ' + tst_result.GetTrustStatusAsString()); end return false; end doctimestamp_signature_field.TimestampOnNextSave(tst_config, opts); # Save/signing throws if timestamping fails. doc.Save(in_outpath, SDFDoc::E_incremental);
Full code sample which demonstrates using the digital signature API to digitally sign, certify, and/or verify PDF documents.
If it is important that a signature in a document have a timestamp that is verifiable with a third-party entity (i.e.
Certificate Authority), then performing DTS would allow verification of when the document was signed. A Certificate
Authority that hosts a timestamp server publicly is known as a
Timestamp Authority (TSA).
Timestamping a signature can be achieved by sending a hash of the signature data to the TSA's timestamping server (
which is what is achieved with the above code sample). If the request is deemed valid, the server will combine the hash
provided by the client and an authoritative date-time of timestamping, signed by a private key from the Certificate
Timestamp Token is then recorded into the document alongside the signature.
If future viewers that open the timestamped and signed document have the same TSA as part of their trust list, then the viewer's PDF viewing application will acknowledge that the signature has been verifiably timestamped.
A chain of certificates, starting with a
root certificate, an
intermediate certificate and an
end-entity certificate, forming a linked path of validation and verification from a trust anchor (i.e. Certificate
Authority) down to an
end-entity certificate. As the name implies, a root certificate is analogous to the root of a
tree, where each branch of the tree is it's own chain of trust.
Note that "chain of trust" is also sometimes known as a "trust path"
A root certificate is the top-most certificate in a
chain of trust/
trust path, the private key of which is used
to "sign" other certificates. All certificates signed by the root certificate inherit the trustworthiness of the root
Act as a middle-man between the protected
root certificate and the
end-entity certificate. Note there is always
at least one
intermediate certificate in a chain of trust, but there could be more than one.
The last in a chain of trust (i.e. a leaf node of the tree) that identifies either a business, a website, or a person.
With respect to digital signatures, identifying the individuals who signed a document is where the trust worthiness of
the chain(s) (i.e. where the
end-entity certificates originated from) is important.
A trusted third party acting as the authoratative entity providing a timestamp, via a timestamp token. Clients who contact a TSA server will create a hashed value (as a unique identifier of the data or file that needs to be timestamped), and send the hashed value to the TSA.
More information about TSAs can be read about in the Time-Stamp Protocol (RFC 3161) industry standard.
A combination of the hash provided by the client and the authoritative date-time of timestamping, digitally signed with the TSA's private key, that is received by the client, and recorded into the document.
Future client applications who open the document will use the TSA's public key to
This new hash is compared to the originally created hash, and if any changes to the data has been made since the timestamp was originally created, then a warning should be raised by the client application.
Get the answers you need: Support