-----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? <quote> I think not. What would be better is if the warning was only logged if the attribute was explicitly set. Mark </quote> 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
