Java APNS Certificate Error with "DerInputStream.getLength(): lengthTag=109, too big."

Question

When I try to using java APNS to send the push notification to iOS, I got this error message:

com.notnoop.exceptions.InvalidSSLConfig: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

I already try converting the certificate to Personal Information Exchange (.p12) also getting the same error. Anyone know to problem and how to resolve it?

Here are my java code:

ApnsService service =
    APNS.newService()
   .withCert("src/net/notification/ck.jks", "******")
   .withSandboxDestination()
   .build();

String payload = APNS.newPayload().alertBody(record.getSendMsg()).build();
String token = record.getToken();
service.push(token, payload);

Thanks.

Immediately

To reproduce: > keytool -list -keystore keystore.jks -storetype pkcs12 gives keytool error: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.. Make sure you specify -storetype when using keytool. – Tempo

Answer 1

I had the same problem but my solution will help you only if you are using maven.

Maven resource filtering (that let's you include variables in your resource files) can mess up your binaries - and certificates are especially sensitive to modification.

In general, binary content shouldn't be filtered. But I couldn't just simply disable resource filtering because I have some .properties files that include variables. So the solution was to exclude .p12 files from filtering.

<build>
    [...]
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
            <excludes>
                <exclude>**/*.p12</exclude>
            </excludes>
        </resource>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>false</filtering>
            <includes>
                <include>**/*.p12</include>
            </includes>
        </resource>
    </resources>
    [...]
</build>

More about maven resource filtering: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

Gwennie

Thank you SO MUCH! I've been bashing my head against this for hours. – Agreement

Answer 2

This occurs because the system thinks you are trying to read a different type of keystore and not JKS. You will need to specify that the file is JKS or convert it to the other format.

I see that you have already tried converting to .p12. If you did this correctly, perhaps there is some other default format. I recommend finding out how to specify JKS instead.

Olvan

Thank you. I am using java app with embedded jetty server. Specifying trustStoreType: JKS made problem go away. – Cougar

fyi: Even files ending with .p12 might not work when used with type "pkcs12" - I just removed the explicitly set type from my server.ssl.trust-store, now it's working – Zwolle

You are correct! In my case I was changing it toPKCS12 but somehow it got out of sequence. This is the command to switch it from JKS to PKCS12 keytool -importkeystore -srckeystore $USERPROFILE\\.keystore -destkeystore $USERPROFILE\\.keystore -deststoretype pkcs12 -deststorepass changeit -srcstorepass changeit – Elyssa

Answer 3

Delete "keystoreType" line

I don't know WHY this works. But if I have this line in my server.xml...

keystoreType="PKCS12"

...then Tomcat will NOT start and give me the DerInputStream.getLength(): lengthTag=109, too big error instead.

But if I DELETE that line then Tomcat will start nicely. No idea why that works. Feels dirty.

---

EDIT: Thanks to Leo's comment from 2022-03-22 I now understand why it was this way: Indeed, somebody had created a JKS file but saved it with a ".p12" filename extension. That was the reason. Then when you explictly tell Tomcat to treat this file as P12, that's when you get this error message. However if you DON'T tell Tomcat the keystore type, then it seems to default to JKS and everything works just fine. -- So in order to avoid confusion: I suggest changing the filename and config to match. So either actually convert the file to p12 and then name it as such. Or leave it as JKS but then change the filename and config accordingly. -- I've also added a Demo section below if you want more information.

---

Demo

Let's do a little demo of how keytool reacts to different stores when you lie about the store type.

I'm using MobaXterm on Windows 10 for this...

$ type keytool
keytool is hashed (/drives/c/Program Files/AdoptOpenJDK/jdk-8.0.282.8-openj9/bin/keytool)
✔

...but I think this should work on Linux as well.

Let's use Java's "keytool" to create a PKCS#12 store...

$ keytool -genkey -alias example-p12-alias -dname cn=exampledname -keystore example.p12 -storepass 123456 -keypass 123456 -storetype pkcs12
✔

...and a JKS store:

$ keytool -genkey -alias example-jks-alias -dname cn=exampledname -keystore example.jks -storepass 123456 -keypass 123456 -storetype jks

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore example.jks -destkeystore example.jks -deststoretype pkcs12".
✔

Some versions of file might not be able to correctly guess the file type...

$ file -k *
example.jks: Java KeyStore\012- data
example.p12: data
✔

...but trid at least guesses that it is something to do with crypto:

$ trid *

TrID/32 - File Identifier v2.24 - (C) 2003-16 By M.Pontello
Definitions found:  14669
Analyzing...

File: example.jks
100.0% (.JKS/KEYSTORE) Java KeyStore (4000/1)

File: example.p12
100.0% (.DER) DER encoded X509 Certificate (2000/1)
✔

Now let's see how keytool react reacts regarding filetype when...

• we let it autodetect filetype.
• we explictly specify the correct filetype.
• we explictly specify the WRONG filetype. So when we lie about the filetype.

JKS with autodetect
Works just fine:

$ keytool -keystore example.jks -storepass 123456 -list
Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

example-jks-alias, 23-Sep-2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): 48:A5:61:DC:F6:4D:7E:2F:FE:07:1B:5D:21:6C:78:13:77:57:06:89

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore example.jks -destkeystore example.jks -deststoretype pkcs12".
✔

JKS with explict correct filetype
Works fine also:

$ keytool -keystore example.jks -storepass 123456 -list -storetype jks
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

example-jks-alias, 23-Sep-2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): 48:A5:61:DC:F6:4D:7E:2F:FE:07:1B:5D:21:6C:78:13:77:57:06:89

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore example.jks -destkeystore example.jks -deststoretype pkcs12".
✔

JKS when we LIE about the filetype
JKS does NOT like that:

$ keytool -keystore example.jks -storepass 123456 -list -storetype pkcs12
keytool error: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
✘

Now let's try the same three cases for PKCS#12 filetype.

P12 with autodetect
Looking good:

$ keytool -keystore example.p12 -storepass 123456 -list
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

example-p12-alias, 23-Sep-2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): DB:8B:4E:B2:7B:D8:B0:5A:5D:87:B6:FB:97:FB:68:1F:48:55:F9:98
✔

P12 with explict correct filetype
Works fine. The only thing that changes is the Keystore provider line (no idea why):

$ keytool -keystore example.p12 -storepass 123456 -list -storetype pkcs12
Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

example-p12-alias, 23-Sep-2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): DB:8B:4E:B2:7B:D8:B0:5A:5D:87:B6:FB:97:FB:68:1F:48:55:F9:98
✔

P12 when we LIE about the filetype
Interstingly this does NOT give an error:

$ keytool -keystore example.p12 -storepass 123456 -list -storetype jks
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

example-p12-alias, 23-Sep-2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): DB:8B:4E:B2:7B:D8:B0:5A:5D:87:B6:FB:97:FB:68:1F:48:55:F9:98
✔

Paxwax

This solution helped me, but not sure whether it will affect or make a security breach? – Involutional

@Involutional this just defaults the keystoreType, according to this: support.ptc.com/help/thingworx/azure_connector_scm/en/… – Biological

Had the same problem with keytool. This helped! Most likely the initial keystore was not of the type pkcs12. Show the type of your keystore with keytool -list -keystore ck.jks. – Confute

Answer 4

If you use maven, this is probably occurring because of the Maven filtering in your whole resources folder. I've tried Zsolt Safrany solution above and did not work. However, reading the documentation he shared, I've found this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-resources-plugin</artifactId>
  <version>3.0.1</version>
  <configuration>
    <nonFilteredFileExtensions>
      <nonFilteredFileExtension>p12</nonFilteredFileExtension>
    </nonFilteredFileExtensions>
  </configuration>
</plugin>

Which excludes binary extensions (or any extension you want) from being filtered.

Joettejoey

Answer 5

I had this problem and figured out the problem is the truststore.p12 is actually in JKS or corrupted.

The keytool command to test the truststore for PKCS12 compliance is:

keytool.exe -keystore truststore.p12 -storepass passwordText -list -storetype pkcs12
keytool error: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

I was able to correct this by doing forced JKS to PKCS12 conversion.

With the following instruction:

 keytool.exe -importkeystore -srckeystore truststore.jks  -destkeystore truststore1.p12 -srcstoretype JKS -deststoretype PKCS12

Than successful test would provide something like:

keytool.exe -keystore truststore.p12 -storepass passwordText -list -storetype pkcs12


Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 3 entries

certificates-4, 9 Jul, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): CF:E3:01:1F:A3:30:C5:B1:B9:2B:C5:28:1B:8C:66:71:EA:B8:67:0D
certificates-3, 9 Jul, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 62:52:DC:40:F7:11:43:A2:2F:DE:9E:F7:34:8E:06:42:51:B1:81:18
certificates-2, 9 Jul, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): FA:5F:98:E8:02:2E:81:05:DB:DF:24:48:65:6A:E5:76:C1:31:CB:28

Reimers

Answer 6

In my case I found that something accidentally changed javax.net.ssl.trustStore system property. SSL debug property -Djavax.net.debug=ssl:trustmanager helped me a lot with investigation.

Stockist