According to the BouncyCastle documentation, the decode function will assume that the passed byte data is a valid BASE64-encoded data:

http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/util/encoders/Base64.html#decode(byte[])

The relevant implementation from the org.cesecore.certificates.certificate.CertificateData.findActiveCertificatesByType (lines 1072-1077) is as follows:

try {
certificateList.add(CertTools.getCertfromByteArray(Base64.decode(base64Certificate.getBytes())));
} catch (CertificateException ce) {
log.error("Can't decode certificate.", ce);
// Continue with the rest of the results, even if this one exploded..
}

In the above code snippet, the base64Certificate value comes from a database. If the certificate data (base64Cert) in table CertificateData is not available (for example it can be "" or NULL), calling the decode function will raise an unhandled exception (either an java.lang.ArrayIndexOutOfBoundsException or NPE). The base64Cert may be empty in cases where VA publisher has been configured not to publish the certificates.

Due to this, a load() exception will be thrown during start-up of JBoss for servlet /status (standalone OCSP responder), and /certificates (certificate store). I have not tested it, but I assume that if the certificate data is invalid, similar exceptions might be thrown.

It would be useful to add some extra logic for handling such exceptions. At the very least the code should handle the empty ("") and NULL values for the base64Cert column. This is especially the case given the comment from the code itself (about continuing with the rest of the results).

By handling these two cases a better error message could be written to the log as well.

Attached is a backtrace of the exceptions thrown.