gopdfadobedigital-signatureacrobat

Subsequent PDF Signature Invalidates Previous Signature

I'm encountering an issue with applying multiple digital signatures to a PDF file generated using an updated version of the Go package github.com/digitorus/pdfsign.

When viewing the document in Adobe Acrobat, the first signature becomes invalidated after subsequent signatures are added.

  1. The first signature is applied and validates successfully.
  2. When a subsequent signature is added, the first signature becomes invalidated (shows as "Invalid" in Acrobat).
  3. Interestingly, each signature validates individually when checked separately.

Only the last signature validates correctly:

Signatures

When checking the first signature using "View Signed Version" in Acrobat, that signature also validates correctly:

View Signed Version

Checking the original or signed document for PDF syntax issues using Adobe Acrobat Preflight does not detect any issues.

Preflight

Based on this similar issue, it seems that when the first signature was applied, the document may have been saved with a minor error. As a result, Adobe Acrobat seems to consider each signature in the PDF broken, except the signature of the full (latest) document.

The issue highlighted above is caused by a segmented xref table, but that is not the case here, as I do not have a segmented xref table. Also, when recreating the entire xref table from scratch, I encounter the same problem.

I suspect there may be another issue with the incremental update.

The incremental update(s) appended to the PDF document looks like:


10 0 obj
<< /Type /Annot /Subtype /Widget /Rect [0 0 0 0] /P 5 0 R /F 132 /FT /Sig /T (Signature10) /Ff 0 /V 12 0 R >>
endobj
11 0 obj
<< /Type /Catalog /Pages 2 0 R /AcroForm << /Fields [7 0 R 10 0 R] /NeedAppearances false /SigFlags 3 /Perms << /UR 12 0 R >> >> >>
endobj
12 0 obj
<< /Type /Sig /Filter /Adobe.PPKLite /SubFilter /adbe.pkcs7.detached /ByteRange [0 5000 7870 414]                   /Contents<308204e306092a864886f70d010702a08204d4308204d0020101310d300b0609608648016503040203300b06092a864886f70d010701a08202903082028c308201f5a003020102021411ea8e89c304b42bad08db8136af460103580f5d300d06092a864886f70d01010b05003057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e3020170d3234313131333039353131315a180f32313234313032303039353131315a3057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e30819f300d06092a864886f70d010101050003818d00308189028181009abbeb66251967f9d298528cb105e0e6c9584d08e3ee7b9e9dccedeca18f56e180f2734eaa21a4b5ffb27a9e61dabf3b8cfbd58d55e32558ce4cac7d1cc85a144087287295ef6890865c387d76bc881d440de1aec0ffa94e9456973bab43f60cc6f7a634955c18c7d3138d97e4182a87a0ef91d7514c079ea900c10fafb954fb0203010001a3533051301d0603551d0e0416041444e2ce2d9b4cb44c2249d05d60d19d0e7dc48f7d301f0603551d2304183016801444e2ce2d9b4cb44c2249d05d60d19d0e7dc48f7d300f0603551d130101ff040530030101ff300d06092a864886f70d01010b0500038181003819e0f84cc3db103a785fd6e5687e3ed844d4ca49d50bde8d9043c823a2a65585508989017dfd65f4e8fd875fcf6c51e09c3884e1749122f10cae161ad0acee6441d1ddb8603270a498f428de7eba1de25a4e68ad8ef91527a7b1f2d937b60856e50ded0fb6bfcec58d6b25d30dc23dca6307a120239407b0d9b5ddb9102db43182021930820215020101306f3057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e021411ea8e89c304b42bad08db8136af460103580f5d300b0609608648016503040203a0820100300f06092a864886f72f01010831023000301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3234313131333131313531305a304f06092a864886f70d01090431420440b35bead7e94a1ac181444e83d78d858feaaad7dee19e84c5b72a5ae5cb69b67fd686fc90d8e2f237200bf4aaa33e0218f669ea924a506dec438d8845896932cf3064060b2a864886f70d010910022f315530533051304f300b0609608648016503040203044048e7b14c70a3beb47b5b8af714af447e03db88f72eba5307afa4c6862537d40fae77371b9a31baeda1a5dcfbe1d7a6a85aa98f64f26a47fdac1de06c06d8eed1300b06092a864886f70d01010d04818074135f1a3f5d6120baa154ccb01f4331df19f9b29cc444ab586091774caa267075642d28f8e8275167fa516d87cc091eecd16dcb7d22992898d774bc8a27cc17c4bef224c1dc60178aeab1f4601b4cb308b0042685d7e0744fd9bde17a3ba0052e519a2a79d3e456d4aca10554b165a910da3b62ef94939b1a6ed72c3d0165820000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000> /TransformMethod /FieldMDP /TransformParams << /Type /TransformParams /Fields [<< /Type /SigFieldLock /Action /All >>] /V /1.2 >> /Name (Jane 2 Doe) /Location (Anywhere) /Reason (Approval Signature 2) /ContactInfo (None) /M (D:20241113121510+01'00') >>
endobj
xref
10 3
0000004592 00000 n 
0000004718 00000 n 
0000004866 00000 n 
trailer
<<
    /Root 11 0 R
    /Prev 4441
    /Size 13
>>
startxref
8131
%%EOF

Files

Solution

  • The signature field values have some strange entries in view to the TransformMethod:

    /TransformMethod /FieldMDP 
/TransformParams << 
    /Type /TransformParams 
    /Fields [
        << 
            /Type /SigFieldLock 
            /Action /All 
        >>
    ] 
    /V /1.2 
>>

    The /Fields value is invalid. It looks like a mix of TransformParams for the FieldMDP transform method and Lock entries of a signature field.

    Also there's an UR key in the documents Perms dictionary referencing the last signature (this is also updated/changed by both signatures). But: There's no UR key for a permissions dictionary defined in the PDF specification.

    Maybe these issues will let the validation engine fail.