On 01/-10/-28163 08:59 PM, [email protected] wrote: > Zitat von Martijn Brinkers <[email protected]>: > >> On 01/-10/-28163 08:59 PM, [email protected] 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. >> >> 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 :-( 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 -- Djigzo open source email encryption _______________________________________________ Users mailing list [email protected] http://lists.djigzo.com/lists/listinfo/users
