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.

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.

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

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

Was this helpful?

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