I have a eSigned / Digitally signed PDF, the document is signed using iText lib in detached signature. I am having issue while verifying the signature, getting message "signers identity is invalid because it has expired or not yet valid" and in signer info "There were errors building the path from signers certificate to an issuer certificate."
I have tried many ways to validate the signature but couldn't get any success. If I explicitly add signers certificate as trusted certificate then I get a green check and able to verify the signature but I think thats not the correct way to do it.
Adobe Signature setting are as follow:-
digitally signed pdf can be found heredigitally signed document
can anyone please help to resolve this issue.
I have tried many ways to validate the signature but couldn't get any success.
That is not surprising: Your signature is not valid. In the PDF signature field value there is a signing time 2020/06/11 09:28:35 GMT but your signer certificate is valid not before 2020/06/11 09:29:44 GMT and not after 2020/06/11 09:59:44 GMT. At the claimed signing time, therefore, your signer certificate was not valid yet and could not create a valid signature.
Apparently you sign using a signing service that creates a short-time certificate just in time when your signature request to it arrives. Unfortunately that is after the time iText stored as signing time in the PDF at the beginning of the signing process.
Thus, one way to resolve the issue is to tell iText to use a time slightly (e.g. two minutes) in the future.
You can do that by means of the PdfSignatureAppearance method setSignDate.
Your signature actually also violates a recommendation from the specification: The afore mentioned signing time stored in the signature field value dictionary should be used only when the time of signing is not available in the signature (the embedded signature container). In your case, though, the embedded signature container does contain a signingTime signed attribute with value 11/06/2020 09:29:44 GMT which is not before the start of certificate validity.
As that only is a recommendation, your PDF signature is not made invalid by having two signing time values. But as the values differ, this can result in different verification results by different validators, using either one or the other value.
Thus, another way to resolve the issue is to make sure no signing time value is added to the signature value dictionary at all. This additionally makes your signed PDF follow the recommendation above and so be more precise.
Unfortunately using the PdfSignatureAppearance method setSignDate to set a null value does not work, later on in the signing process this results in NullPointerException occurrence. But if you use a custom ExternalSignatureContainer implementation in your signing code (and not an ExternalSignature implementation), you can remove that entry in your modifySigningDictionary implementation. The key is PdfName.M.
As an aside, as your signing certificate is only valid for half an hour, validators may also reject it if their validation policy only trusts digital time stamps, not unsecured date-time values.
Thus, you should add revocation information and digitally time stamp the whole construct during the life time of the certificate to guarantee long term validation.
I understand what your issue is. There's a whole new way of solving it, in 3 steps.
Open in Adobe Acrobat DC or any Adobe pdf editor software you have.
In Edit, go to Preferences, in the end come to Signatures. Click on verification, more, in verification time section, select current time. Same location, verification information section, select never.
In Windows integration, tick validating signatures and validating certified documents. Click ok.
Close all popups. Come back to signature area and right click to select, validate signature.
Done ✅
Related
I've read the I-TEXT digital signature e-text, and also previous posts answered by MKL (who seems to be the authority along with Bruno on this topic).
essentially I have an Azure app service that gets the digital sig (base 64) and certificate chain from the company's signing API. The company's signing API returns a signature in Base64 along with a certificate chain.
I just want the to insert a signature object/container into the pdf so it will show in the signature panel when an end user opens up the pdf. I prefer to use deferred signing.
I've shifted from chapter 4's "clientseversigning example" to instead Deferred Signing in MKL's "How to create a PDF signature without knowing the signer certificate early".
The Company API returns a "plain" signature, that I am pretty sure, and also returns a chain of 3 string certificates.
I should note I do have the root and sub certs in advance (2 .cer files) but I am not using them in "prepping" the pdf for hashing right now since the deferred signing example doesn't make use of them obviously. For the container construction code (after getting the response from the Company API), I use the 3 certs chain returned from the company API, but I also tried it with the 2 .cer files, to no avail.
The only difference between my code and the one in the example is instead of byte[] certificateBytes = THE_RETRIEVED_CERTIFICATE_BYTES; X509Certificate x509Certificate = new X509CertificateParser().ReadCertificate(certificateBytes); I build 3 x509Certificates (one for each string in the chain returned from the Company API.
Sadly things wont work, I get these errors in Acrobat: Signature is invalid, There are errors in the formatting or information contained in this signature, signature's identity has not yet been verified, signing time is from the clock on the signer's computer...also if I click Certificate details just below of this error in Acrobat it is blank. This was pretty much the errors I was getting when trying the "clientserversigning example"
I am trying really hard and wondering what it could be... should I try modifying the estimated size from 12000 and bump it up? or the errors I am getting in Acrobat, maybe they are hinting the certificate chain from the Company API is not being picked up by the signing deferral container construction code ... I am struggling but any tips would be so greatly appreciated
Evan
Just to clarify, I am following chapter 4's clientserversigningexample but I am getting the following once my pdf is recreated with the signature from the company API
Its saying 1) there are errors in the formatting of information
2) signer's identity has not been verified
3) signing time is from the clock on the signer's computer
now as far as "prepping" the pdf before hashing it to send for signing...I don't see anything in the ClientSigning example that specifically preps it, can I assume the IText library is prepping it under the hood?
In your question and in your comments to it you appear to be in particular interested in
whether or not one can use a signature API that returns the certificates only together with the signature, and
when to to deferred signing.
Can You Use a Signature API That Provides the User Certificate Only After Signing
To answer this one first has to clarify what kind of signatures the signature API in question creates, plain signature values (e.g. PKCS#1 RSA signatures) or full-fledged CMS signature containers.
If it creates full-fledged CMS signature containers, you can create signatures following arbitrary signature profiles as long as the signature containers follow the requirements for them (which they often do). They only restriction you have is that you cannot have information from the signer certificate in the signature visualization because that visualization is defined in the signed data of the PDF.
If it only creates plain signature values, the best you can do is create and embed simple CMS containers that don't contain pointers to the signer certificate in the signed attributes (if they have any signed attributes as all to start with). Many signature policies of interest do require such pointers, but at least Adobe Reader accepts signatures without.
If you are in this situation and want to try creating signatures with such simple signature containers, you may want to use the code from this answer, section "How to create a PDF signature without knowing the signer certificate early".
When to Use Deferred Signing
The difference between deferred signing and other iText signing calls is not that deferred signing requires less information (compared to ExternalContainer signing).
In contrast to the other iText signing methods, signDeferred re-uses the outermost existing, filled signature field of the PDF to sign and merely replaces the signature container therein.
The method name is derived from the most common use case it’s used for:
In a first step a signature field is (probably first created and then) filled using signExternalContainer with an IExternalSignatureContainer implementation that calculates the document hash to be signed but does not return the final CMS container yet, merely some (usually) empty array. The generated PDF with a filled signature field (albeit without the final signature container) is then temporarily stored (in the file system or a database).
In a second step a signature container for the determined document hash is requested and (probably asynchronously) awaited.
In a final step signDeferred is used to inject the retrieved signature container into the PDF prepared in the first step.
This deferred signing process usually is preferred in setups in which the second step, the signature container creation and retrieval, can take longer than one wants to keep the resources blocked which are required for the document in signing. This includes in particular signatures generated by remote servers or clients, especially if that signing process awaits some third party clearance or activation.
I have a quick question about calculating the digest of a PDF document to use for a digital signature (somewhat related to one of my earlier questions, I'm trying to figure out why you would need to know a client's certificate to create the correct digest).
In Adobe's documentation about the PDF format the following is specified:
A byte range digest shall be computed over a range of bytes in the file, that shall be indicated by the
ByteRange entry in the signature dictionary. This range should be the entire file, including the signature
dictionary but excluding the signature value itself (the Contents entry).
So at this point things seem fairly simple, just digest everything except the /Contents entry in the /Sig dictionary. The actual data in the /Contents entry is specified as followed:
For public-key signatures, Contents should be either a DER-encoded
PKCS#1 binary data object or a DER-encoded PKCS#7 binary data
object.
So still no problems, I can (probably) generate the digest, reserve space for the /Contents entry and attach this PKCS#7 object later on. The confusion starts when I read the following:
Revocation information is a signed attribute, which means that the
signing software must capture the revocation information before signing. A similar requirement applies to the
chain of certificates. The signing software must capture and validate the certificate's chain before signing.
So the thing I'm not quite getting: Apparently the /Contents entry (containing the certificate and signed digest) is not digested, yet the chain of certificates is a signed attribute (and thus needs to be digested?).
I would appreciate it if someone could further specify exactly what is digested, and perhaps better explain the signed attributes to me. The main question that I want to answer is: Can I actually create a signable digest without knowing someone's certificate beforehand? (I'm working with a pkcs7 detached signature)
In short:
Can I actually create a signable digest without knowing someone's certificate beforehand?
In case of SubFilter ETSI.CAdES.detached or adbe.pkcs7.detached you can create the document digest without knowing someone's certificate beforehand.
You usually, though, have to know the signer certificate before starting to generate the CMS signature container to embed into the PDF.
In detail:
(Beware, the following is somewhat simplified.)
I can (probably) generate the digest, reserve space for the /Contents entry and attach this PKCS#7 object later on.
If you first reserve space and thereafter generate the digest, this indeed is how things are done.
The confusion starts when I read the following:
Revocation information is a signed attribute, which means that the signing software must capture the revocation information before signing. A similar requirement applies to the chain of certificates. The signing software must capture and validate the certificate's chain before signing.
So the thing I'm not quite getting: Apparently the /Contents entry (containing the certificate and signed digest) is not digested, yet the chain of certificates is a signed attribute (and thus needs to be digested?).
I would appreciate it if someone could further specify exactly what is digested, and perhaps better explain the signed attributes to me.
The main fact one has to be aware of is that in case of PKCS#7/CMS signature containers signing usually does not merely include one hash calculation but at least two!
The first hash, the document hash, is indeed calculated for the entire file, including the signature dictionary but excluding the signature value itself (the Contents entry) (you might want to read this answer for more details).
But this is not the hash immediately used when applying the signature algorithm.
During the generation of the PKCS#7/CMS signature container (unless in its most primitive form) you create a structure called "signed attributes".
You fill this structure with multiple attributes (name-value-pairs), among them the already calculated document hash but also others, e.g. the Adobe-style revocation information you read about.
When you have finished creating that structure, you hash this structure and generate a signature for it.
You then can put together the PKCS#7/CMS signature container using these signed attributes, the signature, and some more information not signed by this signature, e.g. certificates, signature time stamps, ...
For more details concerning the signature container read this answer.
Finally you embed this signature container into the reserved space in the PDF.
The main question that I want to answer is: Can I actually create a signable digest without knowing someone's certificate beforehand? (I'm working with a pkcs7 detached signature)
In case of SubFilter ETSI.CAdES.detached or adbe.pkcs7.detached you can create the document digest without knowing someone's certificate beforehand.
Depending on the CMS signature profile, though, you usually have to know the signer certificate before starting to generate the signature container because many profiles require the presence of a signed attribute referencing the signer certificate.
Clarifications:
The OP asked some follow-up questions in a comment:
1.: One of the signed attributes is the document hash(without the /contents), so if I understand correctly this is the unsigned hash?
As the "signed attributes" eventually are hashed and signed, that document hash therein is not immediately, directly signed but it is indirectly signed as part of this structure of attributes. So I wouldn't call it unsigned...
In the end when the user really generates a signature, he signs the hash of the PKCS#7 object?
No, the hash of the "Signed attributes" structure which is only a part of the PKCS#7 object, not all of it. There are multiple parts of the PKCS#7/CMS object which are unsigned.
Does the /Contents entry still have a PKCS#7 object that's actually readable for us? (To extract certificates etc for verification)
The Contents entry does contain a full-fledged PKCS#7/CMS signature container object as a binary string. Thus, yes, you can read it (by reading the value of that binary string) and (if you have code that knows how to parse such a signature container) extract information from it.
Beware, though, the signature container may not contain all data required for verification: E.g., if you verify using the chain (not shell) validation model, you might have to extract the signing time from the respective PDF signature dictionary entry.
When verifying a signature, do we simply extract the embedded PKCS#7 object, recalculate the digest, recalculate the digest of the PKCS#7 object and verify this against the signature using the certificate we get from the PKCS#7 object?
You obviously also have to calculate the digest of the signed PDF byte ranges and compare that value with the signed attribute containing the original document digest.(You might have meant that by recalculate the digest.)
As mentioned in the answer to 3, you might have to retrieve additional information from the PDF for use in the PKCS#7 verification.
Furthermore you say the certificate we get from the PKCS#7 object - please be aware that the PKCS#7/CMS signature container may contain multiple certificates. You have to find the correct one. The CMS SignerInfo SignerIdentifier and the ESS signed attributes shall be used for that.
Furthermore you also have to verify validity and trust of the signer certificate.
Is there any good documentation on what authenticated attributes there are?
You can start reading
section 11 "Useful Attributes" of RFC 3852 or RFC 5652: basic CMS
section 12.8 of ISO 32000-1: basic PDF
all of RFC 5126: CAdES
ETSI TS 102778, especially part 2, part 3, and part 4: PAdES
I'm not understanding something. There's a concept called embedding the CRL in a pdf so that if my private key is stolen, I could report it to the CA and they would update their CRL on the web site. I've been reading that the purpose of embedding the CRL in a pdf is good for pdf files with many pages so that the pdf doesn't have to go online to and check for each and every page. Well, problem is, if the CRL is embedded in the pdf instead of having the pdf go check with the CA, then wouldn't it be impossible for revoked certificates to be discovered if the CRL is embedded in the PDF? Am I missing something?
Update:
Even with a TSA time stamp, what is to prevent the thief from using old certificate and embed a CRL that doesn't say his certificate is revoked? This is what I don't get, that to me, the only assured way to prove doc is genuine is both TSA timestamp AND online OCSP. Otherwise, I don't see how an embedded CRL and TSA can ever be enough. With the CRL, it's like allowing the thief to say he is not a thief. Otherwise, there's some sort of misunderstanding on my part about embedded CRL.
Update2 10/1/2014 8:06am pst: Answer below.
"CRLs at top level contain a datetime thisUpdate which indicates the issue date of this CRL. Furthermore it optionally may also contain a datetime nextUpdate" Is there a date and time for each revoked Certificate? A CRL can have many Certificates. If each revoked certificate doesn't have an invalid date, I don't see how it can be determined from what period the certificate and therefore signed document is bad. Answer, page 76 of the white paper does show what a Revocation List look like: it contains the serial numbers of the certificates along with the revocation date. this is how it's determines when the signed documents are bad. However, there appears to be gap of uncertainty after the last signed legit pdf to the time the certificate is reported stolen.
Thanks.
In a nutshell
If you report your key as stolen, it will be revoked at that very time (or even only at the time of the publishing of the next CRL). Thus, your earlier signatures are still considered valid.
If a current CRL is embedded into a PDF during signing, that information can be considered up-to-date for the signature during verification.
To make this work properly, a signature time stamp obviously is necessary, too.
In detail, CRLs
CRLs at top level contain a datetime thisUpdate which indicates the issue date of this CRL. Furthermore it optionally may also contain a datetime nextUpdate which indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. This second field actually is mandatory for CAs conforming to current standards.
Thus, if you embed a CRL in your integrated PDF signature which can be considered current at the time of signing (e.g. a CRL with a nextUpdate after the signing time), a verifier later can use this embedded CRL to deduce that the signer's certificate has not been listed as revoked at the time of signing.
Actually the verification process does not require an independent verifier with his own CRL caches either to update if he already has a CRL with a nextUpdate after the signing time unless the certificate or the CRL contains the freshest CRL extension.
So your worries
if the CRL is embedded in the pdf instead of having the pdf go check with the CA, then wouldn't it be impossible for revoked certificates to be discovered if the CRL is embedded in the PDF?
only indicate a problem for signatures created between the time of the theft and the scheduled issuing date of the CRL update which includes your theft report.
And these signatures will always be a problem for you because they might also be positively verified during that time using other means and result in legal consequences. (So this is why you should choose a CA which re-issues CRLs in short sequence.)
As this verification process heavily relies on the signing time being assured, a signature time stamp is necessary to serve as ascertained source for the signing time.
The same is true for OCSP responses, by the way, they also contain thisUpdate and nextUpdate fields. The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. OCSP responses can likewise be embedded in PDFs.
But how would the system know the earlier signatures (say 1/2014) are still valid? I mean, say you stole my key and used it (say 9/2014), then how does the system distinguish between my legit prior signing of docs (9/2014) vs my docs (1/2014) since we would use the same certificate?
CRLs (and OCSP responses) contain the datetime revocationDate, the date on which the revocation occurred. Signatures from before that date still have to be considered valid (as far as revocation is concerned). As mentioned before, signature time stamps are a necessity for this to work properly.
By the way
You've
been reading that the purpose of embedding the CRL in a pdf is good for pdf files with many pages so that the pdf doesn't have to go online to and check for each and every page.
That is weird, and in general it does not make sense.
No matter how many pages a PDF document has... if you sign it, a single signature suffices to sign the whole document at once. And after that signature you generally are not free anymore to add additional pages to the document.
Context
My overall goal is to make a set of PDFs available, in such a way that users can be assured of the provenance of the documents (i.e., they came from the origin that they are expected to come from). I'm thinking about doing this by digitally signing the PDFs on the server. These signatures won't be in risk of expiring, because the server can just reissue new signed PDFs when the certificate is updated. Using SSL to serve the documents wouldn't be enough, because the files can be passed on to third parties, who don't want/need to access the server.
Problem
The expiration issue arises because some of these PDFs will already have one or more digital signatures (e.g., created for legal purposes). My question is, if the server signs the PDFs, will it also be ensuring the continued validity of the previous signatures, even after they expire, as long as the latest signature is valid?
I'm asking more on the theoretical side, although I plan to implement what I describe using iText, so any pointers on how to use it for my purpose are also welcome.
No, in a PDF all signatures should be validated independently. If you open a PDF with multiple signatures In Adbobe Reader all signatures are validated and you are going to get a warning message if one of the signature validations fails.
If you want to prevent against signature validation issues (for instance a validation failure due to signing certificate expiration) you should look at the PAdES standard (PDF Advanced Electronic Signature) Part #4 (PAdES-LTV Profile - PAdES Long Term Validation). This section of the standard deals with maintaining a proof of the validation across time in order to be able to revalidate the signatures in the future.
I don't know iText very much but it seems that PAdES-LTV is supported since I found this code sample : How to apply verification according to PAdES-LTV
Immagine a web application that lets you digitally sign (with personal digital certificates pkcs12 released by trusted CAs) and timestamp PDF documents with a Java applet or Active X. This must obviously happen on the machine of the user because the private key of the certificate is stored locally.
So once the PDF is signed and timestamped it is uploaded on the server.
Does the uploaded file have the same features of the one created locally? Does it have sense to talk about "the original version of the file"?
I'm a bit confused on this.
Correction:
i mean digitally sign a document with the private key of a personal digital certificate (should be pkcs7, pkcs12) to ensure that it has really been signed by someone and not someone else.
If by "the original version of the file" you mean that you intend to "freeze" the document so that nobody can ever make changes to it again - that is neither possible nor the purpose of a digital signature. Anyone could simply "cut out" the a signature embedded within a document, nobody would notice.
Protecting a document from subsequent modification involves some kind of DRM mechanism. For example, "watermarking" involving steganography is used to protect photos so that noone should be able to claim ownership of a photo, even after having modified it. But the technology is not very advanced yet, most algorithms can be easily broken.
This implies that the notion of "the original version of the file" in let's say a legal dispute is something that the involved parties have to agree upon in consent. There's no way to prove origin without either consent or a trusted third party that will attest the integrity of a document, e.g. if they have an independent copy of the document.
Apart from that, uploading a file should not change its contents. The file will have the exact same properties than the local one including the signature that was added on the client side.
The signature will only attest authenticity and integrity of the document. If it is vital for your application to be able to tell that the signed document received is actually the one that was expected, then I'd advise you to do the following:
Create the PDF on the server
Create a hash of the document (same algorithm that will be used by the signature applet)
Send the PDF to the client
Let the client sign it and send it back
Compare the client's hash with the one previously computed on the server
Validate the signature
Validating the signature will ensure integrity and authenticity, comparing the hashes will guarantee you that the signed document you received on the server is indeed a signed version of the original document previously created.
Concerning timestamps using local clocks: they're worthless, it's very easy to cheat. What you actually should use there is RFC 3161-compliant cryptographically secured timestamps, issued by a trusted third party. Currently that's the only reliable way to include the notion of time in PDF signatures. There's also built-in support for this in Adobe Reader for example. As these services are generally not available for free, it would make sense to add such a timestamp on the server after receiving the signed document. They are added as an unsigned attribute to the CMS (Adobe still speaks of PKCS7) signature, so it won't break the signature and can safely be added after signature creation.
Okay, let's try to answer your question (as I understand it).
You have some software which uses some private key (and a clock) to add a signature to a file.
This signature is depending on the contents of the file, and thus makes sure that the signer knew (or could have known) the contents of the file at the time it signed it. (There are some ways to have "blind signatures", but I assume this is not the case here.)
Uploading the signed file anywhere does not change anything here.
About the timestamp: The key holder can put in any timestamp it wants - so this only helps if you want to prove knowledge of the document at some point in time against the key holder, not if you are the key holder and want to prove that you signed at some point in time and not earlier or later. (Also, are you sure his clock is not skewed?)
About whether this is legally relevant, you will have to ask your lawyer. It might depend on
the jurisdiction in which the signature happened, and the one in which you want the signed document to be valid
whether the owner of the key had a chance to actually read the document before signing
whether the owner of the key had actually a choice of signing or not.
If you use some applet or ActiveX control in the user's browser, I would not be totally sure that the last two points really hold.