Java Certificate Issue - IOException: DerInputStream.getLength(): lengthTag=109, too big

Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Problem

Issue occurs when trying to collect mail from a exchange mailbox.

This can be root cause of outgoing connection failures to Application Links too.

The below error appears in the logs:

 Caused by: java.security.KeyStoreException: problem accessing trust storejava.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
 at sun.security.ssl.TrustManagerFactoryImpl.engineInit(Unknown Source)
 at javax.net.ssl.TrustManagerFactory.init(Unknown Source)
 at org.apache.http.nio.conn.ssl.SSLLayeringStrategy.createSSLContext(SSLLayeringStrategy.java:85)
 at org.apache.http.nio.conn.ssl.SSLLayeringStrategy.createDefaultSSLContext(SSLLayeringStrategy.java:103)
 ... 41 more

Environment

Jira Data Center

Cause

  • The keystore configured for SSL couldn't be read by keytool neither as JKS nor PKCS#12 keystore. So, this can affect Tomcat. 
  • Often how this error occurs is when certs are copied from Windows to Unix ie you have raised a CSR and you have received via email a signed certificate or a set of multiple signed certs from your certificate Authority. A CA could be Verisign or other main stream vendor or even the security team within your organization. 
  • There are extra characters found at the end of the certificate file which the “certificate parser” is attempting to interpret as the start or end of a certificate section. The most common way to encounter this error is to have one, or more, blank lines at the end of the certificate file.  A line termination sequence is permitted (but not required) at the end of the final “—–END”  line (Sometimes you may have more than one encoded cert in a file), but there can be no more than one termination sequence of characters. Reference to webspheretools.com.

Diagnose

PKCS#7/P7B Format

The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extention of .p7b or .p7c. P7B certificates contain "-----BEGIN PKCS7-----" and "-----END PKCS7-----" statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format

The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

For more details you can refer to https://www.sslshopper.com/ssl-converter.html (External Site)

Resolution

  • Re-setup the Certificates
  • Remove the PKCS12 setting for trust store set in the service parameters, but have a back of your .PFX files!
  • Delete everything after the final “—–END” line.  Check the lines using a good editor that shows you the characters being used, don’t trust your eyes.
  • Having back up of the keystore always helps to restore it when disaster happens.

 

(warning) Unfortunately configuring/supporting SSL is not covered under since customers use a variety of products and configurations. A great way to get support for unsupported queries is to ask questions on , our active user-community Q&A site.Atlassian Support OfferingsAtlassian Answers

 

Last modified on Feb 27, 2025

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.