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

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

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

Platform Notice: Server, Data Center, and Cloud By Request - This article was written for the Atlassian server and data center platforms but may also be useful for Atlassian Cloud customers. If completing instructions in this article would help you, please contact Atlassian Support and mention it.

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


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: problem accessing trust DerInputStream.getLength(): lengthTag=109, too big.
 at Source)
 at Source)
 at org.apache.http.nio.conn.ssl.SSLLayeringStrategy.createSSLContext(
 at org.apache.http.nio.conn.ssl.SSLLayeringStrategy.createDefaultSSLContext(
 ... 41 more


  • 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


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 (External Site)


  • 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 Nov 2, 2018

Was this helpful?

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