Hi Mark, Well, anything is 100% better than nothing. Is this "127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any reason or error-code that can point to the reason of failure? Anything that distinguishes it from a 'regular' 400 error originating after the handshake? I'd have to pass it by the compliance experts, but maybe even just this would be enough to convince them I don't need to use the javax.net.debug=ssl:handshake sledge-hammer.
What version will this be in? Mark Boon ________________________________ From: Mark Thomas <ma...@apache.org> Sent: Wednesday, July 31, 2019 8:47 AM To: users@tomcat.apache.org <users@tomcat.apache.org> Subject: Re: Can Tomcat log handshake failures, and where? On 30/07/2019 08:28, Mark Thomas wrote: <snip/> > Generally, processing needs to get as far as presenting a request line > before something is added to the access logs. We could look at expanding > the access logging to include connections that are dropped earlier but > that might be a sufficiently invasive change that it needs to wait until > Tomcat 10. I've done some work on this and it looks promising. The end result is entries like this in the access log for a failed TLS handshake: 127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 - 127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 - 127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 - 127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 - Does this meet your requirement? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
