Update: This problem relates to JDK 6 and earlier, and is handled differently in JDK 7 and up.

Recently we ran into some trouble with the keyword expansion functionality that CVS offers (way too much false positives in the comparisons), and we simply decided to turn it off for our sources. That meant changing the ASCII/Binary property of all files from “ASCII -kkv” to “ASCII -kk” (keyword compression). Problem solved, albeit in a rather crude way.

Well, that sure bit us in the proverbial back end. The point is that when you change this property, you should be careful not to change it for files that were designated “binary”. But we did.

One side effect of this was that a keystore file, stored in CVS, now became ASCII as well; effectively corrupting the file for further use. When trying to read a key from it, I got the following stack trace:

Caused by: java.io.IOException: Too many certificates in chain
   at sun.security.provider.JavaKeyStore.engineLoad(Unknown Source)
   at java.security.KeyStore.load(Unknown Source)

In an attempt to locate the source for this, I stumbled upon this:

sun/security/provider/JavaKeyStore.java#engineLoad(InputStream, char[])

(just scroll down a bit, the top bar covers the important part!)

The first exception that is documented tells us:

java.io.IOException: if there is an I/O or format problem with the keystore data

So from the code in that method, I gather that the occurring problem is actually an OutOfMemoryError (which I feel is kind of creepy) that is caused by the keystore implementation trying to load a corrupted keystore file. I think it’s unlikely that there will be so many chained certificates in any practical keystore that this will really lead to running out of memory, so next time I see this error message I surely will think ‘keystore file corruption’!