RE: warning in tomcat logs
>> This has been fixed in 8.5.x for 8.5.15 onwards and 9.0.x for 9.0.0.M21 >> onwards. Thanks Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: warning in tomcat logs
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Sunday, April 30, 2017 5:02 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: warning in tomcat logs On 29/04/17 15:13, George Stanchev wrote: > TC 8.5.14 and noticed in the logs the following warning: > > "The truststoreProvider [AnyCert] does not support the > certificateVerificationDepth configuration option" > > In our case, we're using Shib's AnyCert trust manager to accept any > client cert on a particular connector as described here [1]. I noticed > that now one can inject the trust manager directly via > "trustManagerClassName" so I am planning to go that route to eliminate > the warning from the logs. But I looked at > JSSEUtils.java#getTrustManagers() and it looks like the warning is > emitted for any algorithm other than "PKIX". My question is, what if > an algorithm implementation doesn't care about > "certificateVerificationDepth"? By setting different algorithm the > user should realize that they are deviating from PKIX and therefore > configuration parameters that apply to PKIX (such as > "trustMaxCertLength" would not be passed down to the trust manager. > Doesn't it make sense to be logged at INFO level? I think not. What would be better is if the warning was only logged if the attribute was explicitly set. Mark Perhaps the intent of the warning was that even if it is not explicitly set, it still will not get pushed into the PKIXBuilderParameters: xparams.setMaxPathLength(sslHostConfig.getCertificateVerificationDepth()); with the default value. So "certificateVerificationDepth" is alsways used in the case of "PKIX" regardless if explicitly set or not. I don't think I am expressing myself very clearly here. IMO the warning should not be emitted for non-PKIX algorithm since there is no way to introspect the algorithm implementation if it supports it or not. I think we will be better served just mention in the documentation that cert verification depth is only applicable to PKIX (which happens to be the default)... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: warning in tomcat logs
On 30/04/17 12:02, Mark Thomas wrote: > On 29/04/17 15:13, George Stanchev wrote: >> TC 8.5.14 and noticed in the logs the following warning: >> >> "The truststoreProvider [AnyCert] does not support the >> certificateVerificationDepth configuration option" >> >> In our case, we're using Shib's AnyCert trust manager to accept any >> client cert on a particular connector as described here [1]. I >> noticed that now one can inject the trust manager directly via >> "trustManagerClassName" so I am planning to go that route to >> eliminate the warning from the logs. But I looked at >> JSSEUtils.java#getTrustManagers() and it looks like the warning is >> emitted for any algorithm other than "PKIX". My question is, what if >> an algorithm implementation doesn't care about >> "certificateVerificationDepth"? By setting different algorithm the >> user should realize that they are deviating from PKIX and therefore >> configuration parameters that apply to PKIX (such as >> "trustMaxCertLength" would not be passed down to the trust manager. >> Doesn't it make sense to be logged at INFO level? > > I think not. > > What would be better is if the warning was only logged if the attribute > was explicitly set. This has been fixed in 8.5.x for 8.5.15 onwards and 9.0.x for 9.0.0.M21 onwards. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: warning in tomcat logs
On 29/04/17 15:13, George Stanchev wrote: > TC 8.5.14 and noticed in the logs the following warning: > > "The truststoreProvider [AnyCert] does not support the > certificateVerificationDepth configuration option" > > In our case, we're using Shib's AnyCert trust manager to accept any > client cert on a particular connector as described here [1]. I > noticed that now one can inject the trust manager directly via > "trustManagerClassName" so I am planning to go that route to > eliminate the warning from the logs. But I looked at > JSSEUtils.java#getTrustManagers() and it looks like the warning is > emitted for any algorithm other than "PKIX". My question is, what if > an algorithm implementation doesn't care about > "certificateVerificationDepth"? By setting different algorithm the > user should realize that they are deviating from PKIX and therefore > configuration parameters that apply to PKIX (such as > "trustMaxCertLength" would not be passed down to the trust manager. > Doesn't it make sense to be logged at INFO level? I think not. What would be better is if the warning was only logged if the attribute was explicitly set. Mark > George > > > [1] > https://wiki.shibboleth.net/confluence/display/SHIB/TomcatClientCertAuthN > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
warning in tomcat logs
TC 8.5.14 and noticed in the logs the following warning: "The truststoreProvider [AnyCert] does not support the certificateVerificationDepth configuration option" In our case, we're using Shib's AnyCert trust manager to accept any client cert on a particular connector as described here [1]. I noticed that now one can inject the trust manager directly via "trustManagerClassName" so I am planning to go that route to eliminate the warning from the logs. But I looked at JSSEUtils.java#getTrustManagers() and it looks like the warning is emitted for any algorithm other than "PKIX". My question is, what if an algorithm implementation doesn't care about "certificateVerificationDepth"? By setting different algorithm the user should realize that they are deviating from PKIX and therefore configuration parameters that apply to PKIX (such as "trustMaxCertLength" would not be passed down to the trust manager. Doesn't it make sense to be logged at INFO level? George [1] https://wiki.shibboleth.net/confluence/display/SHIB/TomcatClientCertAuthN
