Djigzo Error (java.io.EOFException)

Hello

Recently we got the following in the Djigzo Log:

28 Sep 2011 20:44:00 | ERROR Error handling CRL. URI:
http://x500.bund.de/cgi-bin/show_attr?cn=PCA-1-Verwaltung-07&attr=crl
   (mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater thread]
java.security.cert.CRLException: java.io.EOFException: DEF length
68238 object truncated by 67733
  at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRL(Unknown
Source)
  at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRLs(Unknown
Source)
  at
java.security.cert.CertificateFactory.generateCRLs(CertificateFactory.java:517)
  at mitm.common.security.crl.CRLUtils.readCRLs(CRLUtils.java:87)
  at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:245)
  at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:137)
  at
mitm.common.security.crl.CRLDownloaderImpl.downloadCRLs(CRLDownloaderImpl.java:93)
  at
mitm.common.security.crl.CRLStoreUpdaterImpl.downloadCRLs(CRLStoreUpdaterImpl.java:326)
  at
mitm.common.security.crl.CRLStoreUpdaterImpl.update(CRLStoreUpdaterImpl.java:406)
  at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.updateCRLStore(ThreadedCRLStoreUpdaterImpl.java:125)
  at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.access$200(ThreadedCRLStoreUpdaterImpl.java:68)
  at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater$1.doAction(ThreadedCRLStoreUpdaterImpl.java:94)
  at
mitm.common.hibernate.DatabaseActionExecutorImpl$1.doAction(DatabaseActionExecutorImpl.java:149)
  at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:66)
  at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:143)
  at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.run(ThreadedCRLStoreUpdaterImpl.java:82)
  at java.lang.Thread.run(Thread.java:636)

Not sure wjhat this should mean or if i have to worry about.

Thanks

Andreas

The downloaded CRL appears to be corrupt (at least from Java's
perspective). The CRL will be skipped since it's corrupt.

I will check to see what's might be wrong (if any) with the CRL.

Kind regards,

Martijn Brinkers

···

On 01/-10/-28163 08:59 PM, Lst_hoe02(a)kwsoft.de wrote:

Recently we got the following in the Djigzo Log:

28 Sep 2011 20:44:00 | ERROR Error handling CRL. URI:
http://x500.bund.de/cgi-bin/show_attr?cn=PCA-1-Verwaltung-07&attr=crl
(mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater thread]
java.security.cert.CRLException: java.io.EOFException: DEF length 68238
object truncated by 67733
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRL(Unknown
Source)
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRLs(Unknown
Source)
    at
java.security.cert.CertificateFactory.generateCRLs(CertificateFactory.java:517)

    at mitm.common.security.crl.CRLUtils.readCRLs(CRLUtils.java:87)
    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:245)

    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:137)

    at
mitm.common.security.crl.CRLDownloaderImpl.downloadCRLs(CRLDownloaderImpl.java:93)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.downloadCRLs(CRLStoreUpdaterImpl.java:326)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.update(CRLStoreUpdaterImpl.java:406)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.updateCRLStore(ThreadedCRLStoreUpdaterImpl.java:125)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.access$200(ThreadedCRLStoreUpdaterImpl.java:68)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater$1.doAction(ThreadedCRLStoreUpdaterImpl.java:94)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl$1.doAction(DatabaseActionExecutorImpl.java:149)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:66)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:143)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.run(ThreadedCRLStoreUpdaterImpl.java:82)

    at java.lang.Thread.run(Thread.java:636)

Not sure wjhat this should mean or if i have to worry about.

--
Djigzo open source email encryption

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

Recently we got the following in the Djigzo Log:

28 Sep 2011 20:44:00 | ERROR Error handling CRL. URI:
http://x500.bund.de/cgi-bin/show_attr?cn=PCA-1-Verwaltung-07&attr=crl
(mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater thread]
java.security.cert.CRLException: java.io.EOFException: DEF length 68238
object truncated by 67733
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRL(Unknown
Source)
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRLs(Unknown
Source)
    at
java.security.cert.CertificateFactory.generateCRLs(CertificateFactory.java:517)

    at mitm.common.security.crl.CRLUtils.readCRLs(CRLUtils.java:87)
    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:245)

    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:137)

    at
mitm.common.security.crl.CRLDownloaderImpl.downloadCRLs(CRLDownloaderImpl.java:93)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.downloadCRLs(CRLStoreUpdaterImpl.java:326)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.update(CRLStoreUpdaterImpl.java:406)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.updateCRLStore(ThreadedCRLStoreUpdaterImpl.java:125)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.access$200(ThreadedCRLStoreUpdaterImpl.java:68)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater$1.doAction(ThreadedCRLStoreUpdaterImpl.java:94)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl$1.doAction(DatabaseActionExecutorImpl.java:149)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:66)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:143)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.run(ThreadedCRLStoreUpdaterImpl.java:82)

    at java.lang.Thread.run(Thread.java:636)

Not sure wjhat this should mean or if i have to worry about.

The downloaded CRL appears to be corrupt (at least from Java's
perspective). The CRL will be skipped since it's corrupt.

I will check to see what's might be wrong (if any) with the CRL.

This was until now the only problem with this CRL so maybe a partial
read (CRL was replaced while we read it)? Anyway, if it is not
critical we can ignore it. The CRL loading does throw a lot of
Warnings/Errors anyway because of unreachable/not available/wrong
format etc. issues :frowning:
Looks like many CAs does not really care about CRLs.

Regards

Andreas

···

On 01/-10/-28163 08:59 PM, Lst_hoe02(a)kwsoft.de wrote:

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

Recently we got the following in the Djigzo Log:

28 Sep 2011 20:44:00 | ERROR Error handling CRL. URI:
http://x500.bund.de/cgi-bin/show_attr?cn=PCA-1-Verwaltung-07&attr=crl
(mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater thread]
java.security.cert.CRLException: java.io.EOFException: DEF length 68238
object truncated by 67733
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRL(Unknown

Source)
    at
org.bouncycastle.jce.provider.JDKX509CertificateFactory.engineGenerateCRLs(Unknown

Source)
    at
java.security.cert.CertificateFactory.generateCRLs(CertificateFactory.java:517)

    at mitm.common.security.crl.CRLUtils.readCRLs(CRLUtils.java:87)
    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:245)

    at
mitm.common.security.crl.HTTPCRLDownloadHandler.downloadCRLs(HTTPCRLDownloadHandler.java:137)

    at
mitm.common.security.crl.CRLDownloaderImpl.downloadCRLs(CRLDownloaderImpl.java:93)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.downloadCRLs(CRLStoreUpdaterImpl.java:326)

    at
mitm.common.security.crl.CRLStoreUpdaterImpl.update(CRLStoreUpdaterImpl.java:406)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.updateCRLStore(ThreadedCRLStoreUpdaterImpl.java:125)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.access$200(ThreadedCRLStoreUpdaterImpl.java:68)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater$1.doAction(ThreadedCRLStoreUpdaterImpl.java:94)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl$1.doAction(DatabaseActionExecutorImpl.java:149)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:66)

    at
mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:143)

    at
mitm.common.security.crl.ThreadedCRLStoreUpdaterImpl$Updater.run(ThreadedCRLStoreUpdaterImpl.java:82)

    at java.lang.Thread.run(Thread.java:636)

Not sure wjhat this should mean or if i have to worry about.

The downloaded CRL appears to be corrupt (at least from Java's
perspective). The CRL will be skipped since it's corrupt.

I will check to see what's might be wrong (if any) with the CRL.

This was until now the only problem with this CRL so maybe a partial
read (CRL was replaced while we read it)?

If I try to download the CRL with wget it somehow fails (it says "ERROR:
Certificate not present!"). If I download the CRL with Chrome I can
import the CRL without any problem. Perhaps the download sometimes
fails? or bund.de somehow refuses to return the CRL for some reason?

read (CRL was replaced while we read it)? Anyway, if it is not
critical we can ignore it. The CRL loading does throw a lot of
Warnings/Errors anyway because of unreachable/not available/wrong
format etc. issues :frowning: Looks like many CAs does not really care about
CRLs.

Yes most CAs "say" they support CRLs but some of the certs just contain
bogus CRL distribution points. If CRLs are critical, you should only
trust the roots that support CRLs

Kind regards,

Martijn

···

On 01/-10/-28163 08:59 PM, Lst_hoe02(a)kwsoft.de wrote:

On 01/-10/-28163 08:59 PM, Lst_hoe02(a)kwsoft.de wrote:

--
Djigzo open source email encryption