Many loglines for CRL related error

Gateway
1

Hello

found this today. Looks like a little bit too much logging or is there
a real issue?

10 Feb 2012 22:45:01 | ERROR CRL could not be verified. Hash not
correct (mitm.common.security.crl.PKIXRevocationChecker)
[542503743(a)qtp-1820539437-132]
java.security.SignatureException: CRL does not verify with supplied
public key.
at org.bouncycastle.jce.provider.X509CRLObject.verify(Unknown Source)
at
mitm.common.security.crl.PKIXRevocationChecker.acceptCRL(PKIXRevocationChecker.java:800)
at
mitm.common.security.crl.PKIXRevocationChecker.findCRLs(PKIXRevocationChecker.java:863)
at
mitm.common.security.crl.PKIXRevocationChecker.getRevocationStatus(PKIXRevocationChecker.java:239)
at
mitm.common.security.certificate.validator.PKITrustCheckCertificateValidatorImpl.isRevoked(PKITrustCheckCertificateValidatorImpl.java:506)
at
mitm.common.security.certificate.validator.PKITrustCheckCertificateValidatorImpl.isValid(PKITrustCheckCertificateValidatorImpl.java:349)
at
mitm.application.djigzo.ws.impl.CertificateValidatorWSImpl.checkValidity(CertificateValidatorWSImpl.java:255)
at
mitm.application.djigzo.ws.impl.CertificateValidatorWSImpl.checkValidity(CertificateValidatorWSImpl.java:191)
at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
at
mitm.common.hibernate.StartTransactionAdvice.startTransaction(StartTransactionAdvice.java:78)
at
mitm.common.hibernate.StartTransactionAspect.startTransaction(StartTransactionAspect.java:65)
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
at
mitm.application.djigzo.ws.RuntimeExceptionToSoapFaultAdvice.startTransaction(RuntimeExceptionToSoapFaultAdvice.java:70)
at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy74.checkValidity(Unknown Source)
at sun.reflect.GeneratedMethodAccessor440.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:166)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:82)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)

and so on..

This is Djigzo latest (2.3.1-7) and mail flow is fine before and after
this error messages.

Regards

Andreas

2

Hi Andreas,

found this today. Looks like a little bit too much logging or is there a
real issue?

According to the error message, the CRL is either corrupt or the CRL was
not signed by the issuer. Do you have a copy of the offending CRL?

About the logging, there is always a trade-off between too much logging
or too little logging. It's not always easy to distinguish between real
problems on minor problems. I will review the logging statements to see
whether I can make it less verbose for situations like this.

Kind regards,

Martijn

···

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

10 Feb 2012 22:45:01 | ERROR CRL could not be verified. Hash not correct
(mitm.common.security.crl.PKIXRevocationChecker)
[542503743(a)qtp-1820539437-132]
java.security.SignatureException: CRL does not verify with supplied
public key.
at org.bouncycastle.jce.provider.X509CRLObject.verify(Unknown Source)
at
mitm.common.security.crl.PKIXRevocationChecker.acceptCRL(PKIXRevocationChecker.java:800)

at
mitm.common.security.crl.PKIXRevocationChecker.findCRLs(PKIXRevocationChecker.java:863)

at
mitm.common.security.crl.PKIXRevocationChecker.getRevocationStatus(PKIXRevocationChecker.java:239)

at
mitm.common.security.certificate.validator.PKITrustCheckCertificateValidatorImpl.isRevoked(PKITrustCheckCertificateValidatorImpl.java:506)

at
mitm.common.security.certificate.validator.PKITrustCheckCertificateValidatorImpl.isValid(PKITrustCheckCertificateValidatorImpl.java:349)

at
mitm.application.djigzo.ws.impl.CertificateValidatorWSImpl.checkValidity(CertificateValidatorWSImpl.java:255)

at
mitm.application.djigzo.ws.impl.CertificateValidatorWSImpl.checkValidity(CertificateValidatorWSImpl.java:191)

at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)

at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)

at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)

at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)

at
mitm.common.hibernate.StartTransactionAdvice.startTransaction(StartTransactionAdvice.java:78)

at
mitm.common.hibernate.StartTransactionAspect.startTransaction(StartTransactionAspect.java:65)

at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)

at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)

at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)

at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160)

at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)

at
mitm.application.djigzo.ws.RuntimeExceptionToSoapFaultAdvice.startTransaction(RuntimeExceptionToSoapFaultAdvice.java:70)

at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)

at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)

at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)

at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160)

at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)

at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)

at $Proxy74.checkValidity(Unknown Source)
at sun.reflect.GeneratedMethodAccessor440.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:166)

at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:82)

at
org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68)

at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)

and so on..

This is Djigzo latest (2.3.1-7) and mail flow is fine before and after
this error messages.

Regards

Andreas

--
DJIGZO open source email encryption

3

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

Hi Andreas,

found this today. Looks like a little bit too much logging or is there a
real issue?

According to the error message, the CRL is either corrupt or the CRL was
not signed by the issuer. Do you have a copy of the offending CRL?

No, despite the verbosity of the logging i failed to find out which
CRL actualy caused it :frowning:
It also looks like the offender has corrected the problem or is now
included in the "timed-out" section, but it would be useful to not
emitt around 100 lines of logging for data driven errors, no?

About the logging, there is always a trade-off between too much logging
or too little logging. It's not always easy to distinguish between real
problems on minor problems. I will review the logging statements to see
whether I can make it less verbose for situations like this.

A "validation" failure for a CRL is not that uncommen i suspect by
looking at the logs. Most are server errors or time-out and maybe
signing errors should be treated accordingly.

Regards

Andreas

···

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

4

Hello

it looks like the logging is triggered not by the CRL updates but when
browsing the certificate store. I have isolated a pair of
certificate/CA which i can send you in private to test.

Regards

Andreas

5

it looks like the logging is triggered not by the CRL updates but when
browsing the certificate store.

When you browse the certificates, the certificates are validated so the
admin can see whether the certificate is trusted, not expired, not
revoked etc. During the revocation checking the CRLs are checked to see
whether the CRLs are valid and signed by the same issuer as the
certificate. It appears that the CRL is either corrupt or not signed by
the same key as the certificate.

> I have isolated a pair of certificate/CA
> which i can send you in private to test.

Yes please. I will see whether I can determine why the gateway reports
that there is something wrong with the CRLs

Kind regards,

Martijn

···

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