PDF File size of 50kb increases dramatically up to 9mb after signing it with previously using Itext Java Application - certificate

Question

I was a using a custom build itext based java application for digitally signing pdf files.
Every thing was working fine for last one year but recently the size of the output signed pdf file drastically increasing up to 10 MB for just a 50kb source pdf file.
Earlier for a 50 kb file ,the output was less than 300 kb.
Kindly find the code snippets
public void sign(String src, String dest,
Certificate[] chain, PrivateKey pk,
String digestAlgorithm, String provider, MakeSignature.CryptoStandard subfilter,
String reason, String location,
Collection<CrlClient> crlList,
OcspClient ocspClient,
TSAClient tsaClient,
int estimatedSize)
throws GeneralSecurityException, IOException, DocumentException {
// Creating the reader and the stamper
PdfReader reader = new PdfReader(src);
FileOutputStream os = new FileOutputStream(dest);
PdfStamper stamper = PdfStamper.createSignature(reader, os, '\0');
// Creating the appearance
PdfSignatureAppearance appearance = stamper.getSignatureAppearance();
ExternalSignature pks = new PrivateKeySignature(pk, digestAlgorithm, provider);
ExternalDigest digest = new BouncyCastleDigest();
MakeSignature.signDetached(appearance, digest, pks, chain, crlList, ocspClient, tsaClient, estimatedSize, subfilter);
}
public PrivateKey getPrivateKey(String DLL,String PIN,String usage) throws GeneralSecurityException, IOException {
LoggerFactory.getInstance().setLogger(new SysoLogger());
String config = "name=eToken\n" + "library=" + DLL + "\n";
ByteArrayInputStream bais = new ByteArrayInputStream(config.getBytes());
Provider providerPKCS11 = new SunPKCS11(bais);
Security.addProvider(providerPKCS11);
//System.out.println(providerPKCS11.getName());
BouncyCastleProvider providerBC = new BouncyCastleProvider();
Security.addProvider(providerBC);
PrivateKey pk = null;
KeyStore ks = KeyStore.getInstance("PKCS11");
try{
ks.load(null, PIN.toCharArray());
String alias = (String)ks.aliases().nextElement();
java.util.Enumeration<String> aliases = ks.aliases();
while (aliases.hasMoreElements()) {
alias = aliases.nextElement();
//System.out.println(alias);
X509Certificate c = (X509Certificate) ks.getCertificate(alias);
final boolean[] keyUsage = c.getKeyUsage();
if(usage=="0" &&(keyUsage[0] || keyUsage[1]))
{
//System.out.println("Digital Signature");
pk = (PrivateKey)ks.getKey(alias, PIN.toCharArray());
this.providerPKCS11 = providerPKCS11.getName();
this.pub_key = c;
this.chain = ks.getCertificateChain(alias);
for (int i = 0; i < this.chain.length; i++) {
// System.out.println(chain[i]);
X509Certificate cert = (X509Certificate)chain[i];
String tsaUrl = CertificateUtil.getTSAURL(cert);
if (tsaUrl != null) {
tsaClient = new TSAClientBouncyCastle(tsaUrl);
break;
}
}
crlList.add(new CrlClientOnline(chain));
}
else if(usage=="2" &&keyUsage[2])
{
//System.out.println("Encryption");
pk = (PrivateKey)ks.getKey(alias, PIN.toCharArray());
this.pub_key = c;
}
//alias1=alias;
}
}
catch(Exception e)
{
System.out.println("Key Store Not loaded .. PIN entered may be incorrect");
}
return pk;
}
Main function is
token.sign("D:\\15 SAMPLE PDF FILES\\15 SAMPLE PDF FILES\\"+listOfFiles[i].getName(), "D:\\15 SAMPLE PDF FILES\\15 SAMPLE PDF FILES\\sign\\singn_"+listOfFiles[i].getName(), token.chain, PK_sign, DigestAlgorithms.SHA256, token.providerPKCS11, MakeSignature.CryptoStandard.CMS,
"Sign", "Kottayam", token.crlList, token.ocspClient, token.tsaClient, 0);
Last week our firewall changed. Is that the problem?

Answer 1

If the process of signing a PDF suddenly results in much bigger files than before, the reason often is related to embedded validation related information, in particular to embedded CRLs (certificate revocation lists) which may be very large.
The cause might be purely inside the PKI. E.g. if lots of certificates suddenly are revoked after the associated signature creation devices have been found to be insecure, a formerly small CRL may suddenly become very large.
It might also be a matter of connectivity. For example
if the OCSP responder of the PKI was accessible before but suddenly isn't anymore, the signing process might use the CRL instead; or
if the revocation information was not accessible at all before and suddenly is, the signing process also might start using the CRL.
As it turned out, the latter was the case here, as the OP reported:
It was because of the firewall change. Initially the server will not look for crl url and so it doesnt embedd crl since it is not connecting to internet because of the firewall authentication. Unfortunately the firewall change cleared all the authentication and hence the server got the internet access and crl embedds in the signature.
Something like this can be prevented by disallowing use of CRLs. In the case at hand, the Collection<CrlClient> crlList parameter of the sign method can simply be left empty.
Essentially, if you don't want to include CRLs or OCSP responses, don't provide the signing process with means to request them.