Is the PdfPKCS7.loadCacertsKeyStore() deprecated in the last iText version 5.5.6?
It seems yes, so my question is how to verify the authenticity of the certificate and the certificate chain without using load then apply PdfPKCS7.verifyCertificates like we did before?
Any new sample code?
Best regards
Jamil
You ask whether PdfPKCS7.loadCacertsKeyStore() is deprecated in the last iText version 5.5.6. Actually that method has been removed already three years ago in version 5.3.0; back then the whole iText signature API had been overhauled.
For a documentation on the current iText signature API read the white paper Digital Signatures for PDF Documents.
This white paper also contains many code samples, e.g. in section 5.3 Validating the certificates of a signature you can find Code sample 5.5: Verifying certificates:
Certificate[] certs = pkcs7.getSignCertificateChain();
Calendar cal = pkcs7.getSignDate();
List<VerificationException> errors =
CertificateVerification.verifyCertificates(certs, ks, cal);
if (errors.size() == 0)
System.out.println("Certificates verified against the KeyStore");
else
System.out.println(errors);
Related
I want to create an RSA-PSS Signature with ABAP. For Signatures can the function module CALL FUNCTION 'SSFW_KRN_SIGN' be used. It works fine with PKCS1-V1.5, but I need to use RSA-PSS-Padding.
I also found Generate RSA-PSS Signature, but this solution does not solve my issue.
I would really appreciate a small code example, on how I can sign a string lv_str with an SSFA-Store from my SAP system?
I tried different str_format Parameters but none were right.
My Current SSF version is SSFLIB Version 1.850.40 ; CommonCryptoLib (SAPCRYPTOLIB) Version 8.5.39 (+MT) #Copyright (c) SAP, 2011-2021#compiled for linux-gcc-4.3-x86-64#
Running into an issue when using EncodeForHTML for certain characters (Emojis in this case)
The text in this case is:
⌛️a😊b👍c😟 💥🍉🍔 💩 🤦🏼♀️🤦🏼♀️🤦🏼♀️ 😘
Now if I just a straight output
<cfoutput>#txt#</cfoutput>
It displays correctly, no issues, but if I use EncodeForHTML first
<cfoutput>#EncodeForHTML(txt)#</cfoutput>
I get this
⌛️a��b��c�� ������ �� ����♀️����♀️����♀️ ��
I tested it with EncodeForXML & esapiEncode as well to be sure; all are giving me the same result.
I've verified the encoding settings in Lucee are UTF-8, and the meta charset tag is also set to UTF-8. I can't find any documenation re: EncodeForHTML saying if it make any changes to the character encoding, if it requires the character encoding to be something specific, or if it has any known issues with emojis or certain code points.
I appreciate any help or clarification anyone can provide.
Edit: Thank you everyone. Wish I could accept multiple answers.
I was required to sanitize emojis in order ensure that third-party content was cross-compatible with external services. Some of the content contained emojis and was causing export/import problems. I wrote a ColdFusion wrapper for the emoji-java library to identify, sanitize and convert emojis.
https://github.com/JamoCA/cf-emoji-java
For example, the parseToAliases() function "replaces all the emoji's unicodes found in a string by their aliases".
emojijava = new emojijava();
emojijava.parseToAliases('I like 🍕'); // I like :pizza:
To "encode" you could use either the parseToHtmlDecimal() or parseToHtmlHexadecimal() functions prior to using EncodeForHTML().
emojijava = new emojijava();
test = emojijava.parseToHtmlDecimal('I like 🍕'); // I ❤️ 🍕
EncodeForHTML(test);
At the time of this writing, ColdFusion's latest version is 2018 update 9
In turn, it uses ESAPI 2.1.1
Recent release notes don't mention Emoji,
https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation
But they do mention in Pull request 413
"Fixing ESAPI's inability to handle non-BMP codepoints."
This dates from 2017
https://github.com/ESAPI/esapi-java-legacy/pull/413
So based on all this information, I would recommend doing both of the following
Try using ESAPI directly. This is how it was done before ESAPI was added to CF. This issue may or may not still exist in ESAPI
Put in a ticket with Adobe to update this library.
Yes, ESAPI 2.2.0.0 addressed the issue of not correctly encoding non-BMP characters (see https://github.com/ESAPI/esapi-java-legacy/issues/300) as part of PR #413 that James mentioned above.
But I just uploaded release ESAPI 2.2.1.0-RC1 (release candidate 1) to Maven Central early this morning and hope to have an official 2.2.1.0 release out by next weekend, so if you are going to put in a ticket with Adobe for fix this with an updated version of ESAPI, I'd wait another week and then tell them to update to 2.2.1.0.
We have requirement from client , They would like to add Same Signature in all pages (Know the PDF 2.0 Specification contradicts this one )
I ve succeeded some what(not i desired) in implementing the using Itext7.0.4 and itext 5.X
Using Itext 5.X: :
Added "
for (int p = 1; p <= writer.reader.getNumberOfPages(); p++) {
writer.addAnnotation(sigField, p);
} In PdfSignatureAppearance.java class it worked but in the signature panel on left side is showing only one signature
Ive seen the multiple appearance pdf, shows all pages signature in signature panel.
Kindly tell me is it right way of doing (ignore the PDF 2.0 specification ) and how to show all page signature in signature panel
Using Itext 7.0.4
its working as per https://github.com/mkl-public/testarea-itext7/blob/master/src/test/java/mkl/testarea/itext7/signature/ChangeSignatureAppearance.java
But its a 2 step process 1. creating Invisible signature pdf 2. Adding same signature to all pages
It is possible to do this in single step
If not possible kindly tell me which classes need to change or any work around option .
This question already has an answer here:
PDF/A signed with iText7 allows changing attached documents without breaking a signature
(1 answer)
Closed 4 years ago.
I used nitro pro 10/11 to edit a signed PDF document.
Adobe reader can recognize the docs content has been modified, but integrity check is ok by iText (V5.5.6/V7.0.2).
How can i check whether the integrity is correct using iText?
iText offers an API to validate each integrated signature and to check whether it covers the whole document. It does not check, though, whether changes in incremental updates are allowed changes.
Some backgrounds
PDFs can be changed by a mechanism called incremental updates. This mechanism only appends to the file leaving the original bytes unchanged. With each such incremental update a new revision of the file is added to the file.
Integrated PDF signatures sign the complete revision of the document in which they were added to the file with the obvious exception of the actual signature bytes.
Thus, a signature of a former revision still correctly signs its byte ranges even if a later revision completely changes how the PDF is displayed.
As in common signing use cases content someone signed should not be arbitrarily changed, the PDF specification only considers very few types of changes in incremental updates to signed revisions valid, cf. this answer on stack overflow and the documents referenced from there.
What iText's API offers
iText offers an API to validate each integrated signature, in particular this validation checks whether that integrated signature correctly signs the bytes it applies to.
iText furthermore determines whether a signature covers the whole file, i.e. the latest revision of the file.
iText does not offer simple API functions, though, that check whether the changes in incremental updates to signed revisions are all allowed.
This task actually is decidedly non-trivial as the allowed changes are not specified in deep detail; I am not aware of any proper open source implementation of it. Even Adobe Reader in its code for this check has many false negatives for PDFs in which the allowed changes are implemented differently than Adobe Reader would have done it itself, e.g. see this answer.
iText does offer the low-level tools to implement such tests, though, so anyone is welcome to implement them on top of iText.
iText checks in code
You can execute the checks with iText 5.5.10 like this:
PdfReader reader = new PdfReader(resource);
AcroFields acroFields = reader.getAcroFields();
List<String> names = acroFields.getSignatureNames();
for (String name : names) {
System.out.println("Signature name: " + name);
System.out.println("Signature covers whole document: " + acroFields.signatureCoversWholeDocument(name));
System.out.println("Document revision: " + acroFields.getRevision(name) + " of " + acroFields.getTotalRevisions());
PdfPKCS7 pk = acroFields.verifySignature(name);
System.out.println("Subject: " + CertificateInfo.getSubjectFields(pk.getSigningCertificate()));
System.out.println("Document verifies: " + pk.verify());
}
(VerifySignature test testVerifyBabyloveSigned)
The outputs for the OP's sample files are:
babylove_signed.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: true
Document revision: 1 of 1
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051#???#352229198405072013#2], O=[CFCA OCA1]}
Document verifies: true
babylove_signed&modify_by_nitro.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: false
Document revision: 1 of 2
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051#???#352229198405072013#2], O=[CFCA OCA1]}
Document verifies: true
As you see, signed.pdf has only one revision, its integrated signature is valid, and it covers the whole file. signed&modify_by_nitro.pdf has two revisions, its integrated signature is valid but it covers only revision one.
Thus, iText says that while the signature in the latter file does correctly sign its revision, there may be any amount of changes in the second revision.
LicenseKey.LoadLicenseFile is not working for sharepoint project.
When I create a console tool and add itext.licesekey.dll manually, the pdf file is generated without license. But if I add it by PM command Install-Package itext7.licensekey, it works correctly.
Do you have any idea why this could happen?
Thanks in advance,
Toan
There are 2 possible reasons why this is happening:
You're using the wrong version of the license key library which is used for checking your license file.
For iText 5, that library is called itextsharp.licensekey.dll and has a root namespace of iTextSharp. For iText 7, on the other hand, it is called itext.licensekey.dll and has a root namespace of itext.
The NuGet package at https://www.nuget.org/packages/itext7.licensekey, which you installed with PM command Install-Package itext7.licensekey, is the correct license key library for your iText 7 license.
Your manually added license key library is correct, but you didn't add it in the right way so that your project knows where to find it. That is the convenience of the NuGet Package Manager: it makes sure that your libraries are added in the right way. I have never used .NET myself so I can't go into details, but to my understanding, NuGet is sort of like the Maven of the .NET world, as far as dependency management is concerned.
By the way, because you are an iText customer with a valid license key, you probably also have a support contract, and you should ask questions about your license in the iText JIRA. I can't find your login based on your name, every customer can register up to 3 contacts that are eligible for support. Please check with the person in your company who purchased the iText license.
Or you are using a time limited trial license, in which case you can also contact iText Sales for questions about the license.
I have decompiled the itext dlls and figure out in iText.Kernel.Version class, method GetInstance:
string str = "iText.License.LicenseKey, itext.licensekey";
string str1 = "GetLicenseeInfo";
Type type = Type.GetType(str);
if (type == null)
{
Version.version.AddAGPLPostfix(null);
}
The variable type was null.
Please check here for more information how to get dll from GAC
The solution should look like that
I guess the correct string should be like this
string str = "iText.License.LicenseKey, itext.licensekey, Version=2.0.2.0, Culture=neutral, PublicKeyToken=8354ae6d2174ddca";