SSDLC Compliance

[GAN Kok Leong, Adrian]

Hi,

We have a cybersecurity requirement for all software. We would like to know 
whether Tomcat version 7.0.25 is developed and comply with Secure Software 
Development Life Cycle (SSDLC)?

Regards
Adrian Gan


[This e-mail is confidential and may be privileged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Reset a single mod_jk worker counter

[Rainer Jung]

Hi Chris,

Am 05.12.2016 um 22:25 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Ping. I'd really like to be able to do this. Is it currently possible?

When locating this message to reply to it, I found essentially the
same message posted by me back in May. :)

Thanks,
- -chris

On 11/21/16 9:24 AM, Christopher Schultz wrote:

All,

When using the mod_jk status worker in read-write mode, you can
edit a worker (or sub-worker for an lb worker) and adjust certain
settings like the timeouts, lbfactor, etc. You can also reset the
stats on the worker back to zero.

I'm interested in resetting the "errors" stat but not the remaining
stat s.

Is that possible?


No, not currently. Since long term stats IMHO mostly make sense when 
grabbing them regularly via some monitoring, what's bad about resetting 
the other stats as well, so that at least all numbers give a consistent 
view?


Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Sat, Dec 3, 2016 at 2:28 PM Mark Thomas  wrote:

> On 03/12/2016 17:39, John D. Ament wrote:
> > Sorry missed a response..
> >
> > On Sat, Dec 3, 2016 at 12:36 PM John D. Ament 
> > wrote:
> >
> >> On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> > John,
> >
> > On 11/26/16 7:29 PM, John D. Ament wrote:
>  Hi,
> 
>  Looking for some external input.  I've put together a simple
>  tomcat embedded instance designed to deploy an arbitrary set of
>  servlets, filters, etc.
> 
>  For some reason, when I run tests with Tomcat the server never
>  fully launches.  I can see the port in use, but connections to the
>  server are not answered by the instance.  When I debug the start
>  up, I see what appears to be a loop attempting to start services
>  that never returns, in LifecycleBase.
> >
> > So you see a busy-loop? What's the stack trace?
> >
> >
> >> I am probably seeing a busy-loop, however I  see no stack traces.
>
> Take a thread dump.
>
> Better, take 3 ~10s apart and compare.
>
> > Tomcat version?
> >
> >
> > 8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can
> recall
> > recently)
> >
> >
> >
>  Easiest way to reproduce it with this project is to clone
>  https://github.com/hammock-project/hammock/ and run a local build
>  (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
>  from rest-resteasy (or spark or jersey).
> >
> > Er... sorry, I'm not going to do that, and it doesn't look like anyone
> > else is going to do that, either.
> >
> >
> > Its always worth a shot.
> >
> >
> >
>  I'm sure there's something simple I'm over looking.
> >
> > I browsed your github repo for about 15 seconds until I realized that
> > there are like 10k files and I'd never find the embedded driver
> > without asking. So, where is it?
> >
> > Can you compare your driver with any of the many Tomcat test cases
> > that launch an embedded server instance? Those test classes do exactly
> > what it sounds like you are trying to do.
> >
> >
> > Happily, can you point me to some of these test cases?
>
> Most of them under trunk/test
>
> This one has several variations:
>
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?view=annotate
>
>
> > On a related note, documentation for tomcat embedded is scarce.  I
> usually
> > have to find it on non-apache channels.  What would be the best way to
> get
> > a document page started, maybe linked off of
> > http://tomcat.apache.org/tomcat-8.5-doc/index.html ?  What repo contains
> > your site?  I'd be happy to provide some patches from my own learnings.
>
> The docs are taken from the releases so you need to start here:
>
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/
>
>
So I was able to identify my issue.  It's not specifically a tomcat
problem, but tomcat's bootstrapping makes it unique.

one of the issues I've observed is that Tomcat's use of multithreading
causes some thread deadlocking with some synchronized blocks.  I was
wondering if there's a way to turn that off?  Make tomcat's bootstrap
happen in the same thread as the original invocation?


>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Connector bindOnInit=false not behaving as expected

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/4/16 3:24 PM, Mark Thomas wrote:
 It looks like the ProtocolHandler is really the place where
 the TLS configuration is taking effect, and not the
 Connector, so I'm largely ignoring the Connector for now. Is
 that the right choice to make, here?
> 
> It depends. What you actually need to do is swap out the
> SSLContext. This is in the SSLHostConfigCertificate.

It looks like the only place the SSLContext is actually set is from
Nio(2?)Endpoint.bind(). So that means that, with the current Tomcat
implementation, changing the SSLContext means an unbind() followed by
a bind(). Do I have that correct?

This would be for JSSE only... for OpenSSL/APR, I suspect it will be
the same thing, but any change would have to take both into account.

What I'd really like to be able to do is replace the SSLContext
without dropping any in-flight requests, while new requests wait to be
serviced until the new configuration was available. Something like this:

1. Stop processing incoming connections (e.g. still accept(), but
don't handshake, yet... or at least stay bound to the port, but don't
yet accept() and allow the TCP stack backlog to queue incoming
connections)

2. Load the new TLS configuration

3. Resume accepting connections with the updated TLS configuration

4. Requests accepted before step #1 continue to use the configuration
effective at the time

I'm not sure how all that squares with that JSSE is willing to do.
Once the TLS handshake occurs, presumably it means that the connection
will continue to be valid until it's closed. If a connection as
mentioned in #4 above is long-running, the old SSLContext etc. will be
GC'd after the connection finally closes. If that assumption is not
correct, I don't think any of the above is even possible.

What probably is possible is pausing all incoming connections, waiting
X ms for them to complete, then unbind(), then bind(). Client
observation would be that the service seems to stall, then fail.
Presumably, immediately re-trying would connect and get the new
configuration.

How difficult do you think it would be to implement such a "graceful"
shutdown of the connector? It would be the same as "stop" except that
it would first allow all in-flight requests to complete (with some
reasonable timeout... say, as specified by a parameter to a
gracefulShutdown(int) call?) and then, in the case of the
bindOnInit="false", it would unbind().

That would allow a JMX client to say "shut down gracefully", waiting
for an OK response (which would indicate that the connector had in
fact shut down), then immediately request a "start" and the connector
would come back up. At this point, I'd probably argue that we should
add a "restart gracefully" to the list of JMX-callable actions which
just does both of those calls on the server without a second HTTP
roundtrip from the JMX client.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYRfJcAAoJEBzwKT+lPKRYYz4P/RiXs43l3pCXS5RmivlhaIg2
QSTq2Og50I8+qK6wuhpABp0VvwOI29JQ0M+Bg2jSMM7sFRpnH+Z6brPOKArMwrYz
fBRgg0HfwFJQqAFk+wdXfoSNkbvHtsvZIhrrPcJGth9Tr/BHwDXHcmCKmScTCg93
ynyw6AWDzZ8SxU1YpKHYhBXb1Zbz4KDGcxBLDcRs6S4qmnNeu2JQfn7xQNImPZg0
yToctnzzH/SRG2rEoySyKMY+jpynreMw9jUOmdygJaGh1r3dv00yivu08Dv9/8MI
yiQCq678sa0U5pUKTZtvhb00ZszmCZ56dJTC0u51nSTWOkrj+AmaBjmWIR1CUdMO
qO2PhRsL/EnYDeEYORcLuJ1oa+J3GcxplgsU0PX09vVN+7TF7F3h0oUH34PvMyIJ
hrLQv958nMevodkeDEgW5/nVV8WctXXUbSgKG4IFufwPh3paMmqsO+9ea8/vnXWN
iAnijwgRun2Cwl2CrjPDu9isN5zoLQTlyYJnw+tOE4JYFjCpLVJ8ykTeRQs/fSDD
qEuMIAT3+MrNTIMN8c5zBoGxTIouWRuXDetpSlaVm2Ln1R4TghdkBf+D4RdBiMhV
ED08VnzghwbuG6VpdbFTjTThj5qEb+SLiQmM7rf9WF36s7Gatl4z1FyTJn7gtj2+
Uvwqqd0kXA/XFnpmttHA
=qvTT
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Connector bindOnInit=false not behaving as expected

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/4/16 3:24 PM, Mark Thomas wrote:
> On 04/12/2016 20:09, Christopher Schultz wrote:
>> All,
>> 
>> On 12/1/16 6:07 PM, Christopher Schultz wrote:
>>> All,
>> 
>>> On 12/1/16 5:59 PM, Christopher Schultz wrote:
 All,
>> 
 I'm trying to use JMX to do things with Tomcat Connectors and
  ProtocolHandlers. Specifically, I'd like to re-load the
 keystore (really certificate) used for an HTTPs connection.
>> 
 I'm currently using Tomcat 8.0.30 for my testing.
>> 
 It looks like the ProtocolHandler is really the place where
 the TLS configuration is taking effect, and not the
 Connector, so I'm largely ignoring the Connector for now. Is
 that the right choice to make, here?
> 
> It depends. What you actually need to do is swap out the
> SSLContext. This is in the SSLHostConfigCertificate.

Yeah, I knew I really needed to swap-out the SSLContext. I wasn't sure
how easy that would be, so I started out with what was possible with JMX
.

 It seems that calling the pause()/resume() or stop()/start()
 on the ProtocolHandler have no effect on resetting the 
 SSLServerSockeyFactory, which is what would be required to 
 achieve my goals (update a certificate for a running Tomcat 
 instance).
> 
> You need new code to do this if you want to handle it smoothly.
> Failing that, you need to trigger bind(). Which means: 
> bindOnInit=false start() stop()
> 
> change TLS config
> 
> stop() * drop existing connections, new connections fail here *
> this is generally a Bad Thing (tm) start()
> 
> new TLS config available

I'll have to check again, but above I was talking about the protocol
handler, not the Connector. I believe that bouncing the protocol
handler does not reload the certificate, etc.

 I suspect I'll have to call init(). When I do this without 
 specifying bindOnInit=false awful things happen. First,
 calling init() gets me an error on stdout that the address is
 already in use, and then it's basically not possible to
 restart the ProtocolHandler after that point: it's dead as
 far as I can tell, because you can't call start() or resume()
 without getting a whole bunch of errors.
> 
> You can't just call any method you like. You have to respect the 
> standard Lifecycle state transitions even though Endpoint doesn't 
> enforce them (the Interface and supporting base classes are not
> visible to the package.

:)

Yeah. I was just flailing about a bit, here.

 Does that sound like a problem to anyone? I would think that
  failure to call init() would leave the ProtocolHandler in an
  uninitialized state, but I'm wondering if trying to 
 RE-initialize the ProtocolHandler should be something that
 won't damage a previously-initialized component. When trying
 to script these types of connections, having a
 non-destructive init() might be useful.
> 
> This is not a problem.

Ok.

 So, I set bindOnInit="false" which is documented[1] to unbind
 on "stop". When calling stop(), the port continues to be
 bound by Tomcat. Calling stop() and then start() throws a
 BindException. :( Destroying the ProtocolHandler also leaves
 the port still bound, and also (unsurprisingly) destroys the
 ProtocolHandler.
> 
> That sounds like a possible problem but we have unit tests that 
> explicitly test this behaves as expected (TestXxxEndpoint) so a
> Tomcat bug looks unlikely.

I think this ended up being an error with the keystore itself which
caused the connector to get itself into a stat from which it could not
be resurrected. I'll repeat my observations with a bit more care and
report back. I think there is in fact something here that could be
improved.

 Stopping the Connector also does not release the port. :(
 Calling stop() and then start() also throws a BindException.
>> 
 At this point, I think I'm stuck. Is there a bug here?
>> 
 I'm going to upgrade to 8.0.latest and repeat my tests, just
 in case.
>> 
>>> I updated to 8.0.39 and noticed that I had moved my keystore
>>> out of the way temporarily and so the connector was failing at
>>> some point looking for that. I'll be repeating my tests with
>>> more attention to detail, but what I think I've noticed is that
>>> there are certain errors which can occur that cause the
>>> Connector to get itself into a bad state.
>> 
>>> Specifically, I think that problems with the crypto setup
>>> cause the connector to bind to the port, then fail and not
>>> unbind. Any later attempt to re-start the Connector fails
>>> because the port is still bound.
>> 
>>> I think the connector should catch (some?) exceptions and
>>> unbind the port in those cases when bindOnInit=false.
>> 
>> Any comments on whether or not these items should be considered
>> bugs? Specifically, uncaught exceptions which can prevent the
>> connector from coming back up again?
> 
> If you find a sequence 

Re: Reset a single mod_jk worker counter

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Ping. I'd really like to be able to do this. Is it currently possible?

When locating this message to reply to it, I found essentially the
same message posted by me back in May. :)

Thanks,
- -chris

On 11/21/16 9:24 AM, Christopher Schultz wrote:
> All,
> 
> When using the mod_jk status worker in read-write mode, you can
> edit a worker (or sub-worker for an lb worker) and adjust certain
> settings like the timeouts, lbfactor, etc. You can also reset the
> stats on the worker back to zero.
> 
> I'm interested in resetting the "errors" stat but not the remaining
> stat s.
> 
> Is that possible?
> 
> Thanks, -chris
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYRdtAAAoJEBzwKT+lPKRYedkP/3ZeSsV7zZbFgVrq46wuETp7
pNDLbm+DCyzy812H6Rplme/oKoTkNWlTPqm5BWPrcyhxTQVOtRQCVq3fTF8YCS0l
ouvQJ0VPUm1+m2mLb2Ke0m5y+q/hCukH9O2bT05NOmjff30GGjEl39+o2HO3BRwe
k5Iyr1NXNze34x5zMsMyicUW7K38/xt1pKLANdGH3k5eVMFMk0ZeWmpmr9SOK78S
52+v5t7Ge2oQHpC9qWkzqOAw2YAtMbrJM0RlFdEtNvh4JqTfnnaoRFRqItlhw6xm
As+XWhrOgNSvGu22PnYOT10Gv7rPpYxr2J33aaBXyF4FhmaiD22EdpMTe4mKCZ5h
bnxpBKpKC4Nv9Xcg7YaUWuXwuNDHWdJuFRf616btEYCPHTDHwBHEeXoiHC/aypio
1lCvWTU6XVvEiLSaV0mB5k4ZC/weOnu35GXSHG3HtMlJo9eBNHVyDOLpP1IM6FsO
dLjlZaMf01zt6etIDQ3UICUTcy9mv/bLsgLo/03qhGdg94FvdmtRPLvq8uvGPGTH
BfcBJN6jgD7iPGnCzq1d0MJ3/t4oNWePvHbJqp1fo/hWnUFfS4rR4S7pngxIr7I/
dnxNVOl0Q0o/mp3IkZYINhg1VSwDyqeyroD0VW1l6/9m8eziylgawDAsrm9PBjq1
pHWb6RIrYOCcC0AD1wpA
=jgyA
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unable to get SSL working on Tomcat 8.5

[Mark Thomas]

On 05/12/2016 18:33, Jim Weill wrote:
> 
> 
> On 12/5/2016 8:43 AM, Mark Thomas wrote:
>> On 05/12/2016 16:13, Mark Thomas wrote:
>>> On 01/12/2016 22:17, Jim Weill wrote:
 sslEnabledProtocols is now just protocols for one thing. And you
 have to
 put your certificate stuff in an  sub-section to the
 connector now.
>>> That should not be necessary. Tomcat should handle the conversion for
>>> you under the hood.
>>>
>>> I've tested this with a JKS store but not a pkcs12 store. Let me see if
>>> there is something extra we need to do in the pkcs12 case.
>> Confirmed. This is working as expected. The following works with 8.0.x
>> and 8.5.x. I've built both from trunk but there are no relevant changes
>> since the last release of each.
>>
>> > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="150"
>> SSLEnabled="true"
>> scheme="https"
>> secure="true"
>> clientAuth="false"
>> sslProtocol="TLS"
>> keystoreFile="conf/localhost-rsa.p12"
>> keystoreType="PKCS12"
>> keyPass="changeit" />
>>
>> Mark
>>
> 
> 
> So what might have changed with tomcat between 7.0 and 8.5 then?  I
> upgraded from 7.0 to 8.5 and had to do the separate SSLHostConfig
> section and change to the more updated connector syntax when a single
> connector string as shown above used to work.

The auto-switching to use the OpenSSL encryption could be a factor.
Although any error is likely to include OpenSSL support classes in the
stack trace.

Another possibility is alias handling although that also looks to be
OpenSSL related. I've found at one case where a keystore with a single
key/cert/chain fails. I'm currently working on a patch for that. It
should make it into a release in the new year.

Tracking down the root cause is likely to involve debugging both the TLS
handshake and the TLS connector initialisation. If you are able to that,
great. If not, if you can provide a sample configuration - including
dummy keys, certs and chains - that fails that others can use to debug
then that would very helpful.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unable to get SSL working on Tomcat 8.5

[Jim Weill]

On 12/5/2016 8:43 AM, Mark Thomas wrote:

On 05/12/2016 16:13, Mark Thomas wrote:

On 01/12/2016 22:17, Jim Weill wrote:

sslEnabledProtocols is now just protocols for one thing. And you have to
put your certificate stuff in an  sub-section to the
connector now.

That should not be necessary. Tomcat should handle the conversion for
you under the hood.

I've tested this with a JKS store but not a pkcs12 store. Let me see if
there is something extra we need to do in the pkcs12 case.

Confirmed. This is working as expected. The following works with 8.0.x
and 8.5.x. I've built both from trunk but there are no relevant changes
since the last release of each.



Mark




So what might have changed with tomcat between 7.0 and 8.5 then?  I 
upgraded from 7.0 to 8.5 and had to do the separate SSLHostConfig 
section and change to the more updated connector syntax when a single 
connector string as shown above used to work.


jim


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat Realm/LDAP - userRoles and Organization Unit name for authenticated users

[Taylor, Larry]

Hi Felix

If isUserinRole  has information to make determination to different component 
accesses in the application that would be sufficient - although,  what I  
really need to know is what department or Organizational unit they belong to 
after authentication in order to give them specific page component accesses.

Any help on this is appreciated. 




-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Sunday, December 04, 2016 2:17 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Realm/LDAP - userRoles and Organization Unit name for 
authenticated users

Am 04.12.2016 um 08:04 schrieb Taylor, Larry:
> Hello,
>
> For  Users that have authenticated  from the Web Login page through Tomcat 
> Realm LDAP configuration is it possible to get the authenticated user's 
> ou=Organizational Unit or Department name?   and also what their role names 
> are?   I need this information to pass to a servlet or jsp page.
>
> I saw documentation about the java.security.Principal class but could not 
> find any documentation or examples on how to get this type of information 
> after users are authenticated.
>
> I am able to get the username with  ${pageContext.request.userPrincipal.name} 
> &  request.getRemoteUser(); but nothing about how to get the user's member 
> affiliations and roles.
The standard way to get the roles is to iterate over your expected roles and 
ask for request.isUserInRole(role). The servlet spec has no API to get directly 
a list of roles.

If you are willing to bind yourself to the implementation of JNDIRealm you 
could get the list of roles. But I don't recommend it, as that implementation 
is not guaranteed to stay stable.

Do you really need to get the list, or is isUserInRole enough?

Regards,
  Felix
>
> Any information or pointers on this is appreciated.
>
>
> 
> Larry Taylor
>
>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unable to get SSL working on Tomcat 8.5

[Mark Thomas]

On 05/12/2016 16:13, Mark Thomas wrote:
> On 01/12/2016 22:17, Jim Weill wrote:
>> sslEnabledProtocols is now just protocols for one thing. And you have to
>> put your certificate stuff in an  sub-section to the
>> connector now.
> 
> That should not be necessary. Tomcat should handle the conversion for
> you under the hood.
> 
> I've tested this with a JKS store but not a pkcs12 store. Let me see if
> there is something extra we need to do in the pkcs12 case.

Confirmed. This is working as expected. The following works with 8.0.x
and 8.5.x. I've built both from trunk but there are no relevant changes
since the last release of each.



Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Unable to get SSL working on Tomcat 8.5

[ramagopala.chaturvedula]

It's working for me with the configuration attributes apart from your 
configuration :

sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation". 
keystoreFile="certificate path" in the  element.

I couldn't succeed with the element 

-- Ram.


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, December 05, 2016 10:14 AM
To: Tomcat Users List
Subject: Re: Unable to get SSL working on Tomcat 8.5

** This mail has been sent from an external source **

On 01/12/2016 22:17, Jim Weill wrote:
> sslEnabledProtocols is now just protocols for one thing. And you have
> to put your certificate stuff in an  sub-section to the
> connector now.

That should not be necessary. Tomcat should handle the conversion for you under 
the hood.

I've tested this with a JKS store but not a pkcs12 store. Let me see if there 
is something extra we need to do in the pkcs12 case.

Mark


>  Here's how ours had to be reconfigured (on 8443 instead of 443) using
> NIO and JSSE:
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150"
> SSLEnabled="true" protocols="TLSv1.2">
> 
>  certificateKeyFile="path-to-cert-keyfile" />
> 
> 
>
> Hope this helps.  The parts that are relevant to your certificate are
> in the section here:
> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_
> -_SSLHostConfig but scroll up slightly to get the instructions on how
> to use this subsection.
>
> jim
>
> On 12/1/2016 1:26 PM, Bartlett, Todd wrote:
>> Thanks for your reply, unfortunately I know very little about Tomcat
>> beyond the server.xml config below.
>> What are "hooks" and or whats been deprecated related to the below,
>> or is there a new example config for using a .pfx Keystorefile?
>>
>> > protocol="HTTP/1.1"
>> SSLEnabled="true"
>> maxThreads="150"
>> scheme="https"
>> secure="true"
>> keystoreFile="C:\.pfx"
>> keystorePass=""
>> keystoreType="pkcs12"
>> clientAuth="false"
>> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." />
>>
>> -Original Message-
>> From: Jim Weill [mailto:moon...@icsi.berkeley.edu]
>> Sent: Thursday, December 01, 2016 2:38 PM
>> To: Tomcat Users List 
>> Subject: Re: Unable to get SSL working on Tomcat 8.5
>>
>> Are you using the 8.5 reference?
>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
>>
>> When we updated to 8.5, we also found things changed with the
>> connector for SSL.  The above page is the current guide, and you'll
>> notice several of the hooks have been deprecated since 6.0
>>
>> jim
>>
>> On 12/1/2016 11:28 AM, Bartlett, Todd wrote:
>>> Thanks for replying, some more information.
>>>
>>> Tomcat 8.0 works fine with this configuration (Ive tested both
>>> installs on same server, same .pfx) (note no other changes anywhere,
>>> just a fresh install and modifying the server.xml) We have been
>>> using this config since 6.0 through 8.0.
>>>
>>> Something changed in 8.5, it does not seem to recognize or load the
>>> .pfx file anymore.
>>>
>>> Thanks
>>>
>>> Todd
>>>
>>> -Original Message-
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>>> Sent: Wednesday, November 30, 2016 8:52 PM
>>> To: Tomcat Users List 
>>> Subject: Re: Unable to get SSL working on Tomcat 8.5
>>>
> Todd,
>
> On 11/29/16 4:41 PM, Bartlett, Todd wrote:
> The below settings work fine on 6.0 version (no other changes Im
> aware
> of)  Error received Failed to initialize component
> [Connector[HTTP/1.1-443
> What's the rest of the error message?
>
>  maxThreads="150" scheme="https" secure="true"
> keystoreFile="C:\.pfx" keystorePass=""
> keystoreType="pkcs12" clientAuth="false"
> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." />
> Looks okay so far. You need to post more information.
>
> -chris
>>>
>>> 
>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>> 
>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: Unable to get SSL working on Tomcat 8.5

[Mark Thomas]

On 01/12/2016 22:17, Jim Weill wrote:
> sslEnabledProtocols is now just protocols for one thing. And you have to
> put your certificate stuff in an  sub-section to the
> connector now.

That should not be necessary. Tomcat should handle the conversion for
you under the hood.

I've tested this with a JKS store but not a pkcs12 store. Let me see if
there is something extra we need to do in the pkcs12 case.

Mark


>  Here's how ours had to be reconfigured (on 8443 instead
> of 443) using NIO and JSSE:
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150"
> SSLEnabled="true" protocols="TLSv1.2">
> 
>  certificateKeyFile="path-to-cert-keyfile" />
> 
> 
> 
> Hope this helps.  The parts that are relevant to your certificate are in
> the section here:
> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig
> but scroll up slightly to get the instructions on how to use this
> subsection.
> 
> jim
> 
> On 12/1/2016 1:26 PM, Bartlett, Todd wrote:
>> Thanks for your reply, unfortunately I know very little about Tomcat
>> beyond the server.xml config below.
>> What are "hooks" and or whats been deprecated related to the below, or
>> is there a new example config for using a .pfx Keystorefile?
>>
>> > protocol="HTTP/1.1"
>> SSLEnabled="true"
>> maxThreads="150"
>> scheme="https"
>> secure="true"
>> keystoreFile="C:\.pfx"
>> keystorePass=""
>> keystoreType="pkcs12"
>> clientAuth="false"
>> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." />
>>
>> -Original Message-
>> From: Jim Weill [mailto:moon...@icsi.berkeley.edu]
>> Sent: Thursday, December 01, 2016 2:38 PM
>> To: Tomcat Users List 
>> Subject: Re: Unable to get SSL working on Tomcat 8.5
>>
>> Are you using the 8.5 reference?
>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
>>
>> When we updated to 8.5, we also found things changed with the
>> connector for SSL.  The above page is the current guide, and you'll
>> notice several of the hooks have been deprecated since 6.0
>>
>> jim
>>
>> On 12/1/2016 11:28 AM, Bartlett, Todd wrote:
>>> Thanks for replying, some more information.
>>>
>>> Tomcat 8.0 works fine with this configuration (Ive tested both
>>> installs on same server, same .pfx) (note no other changes anywhere,
>>> just a fresh install and modifying the server.xml) We have been using
>>> this config since 6.0 through 8.0.
>>>
>>> Something changed in 8.5, it does not seem to recognize or load the
>>> .pfx file anymore.
>>>
>>> Thanks
>>>
>>> Todd
>>>
>>> -Original Message-
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>>> Sent: Wednesday, November 30, 2016 8:52 PM
>>> To: Tomcat Users List 
>>> Subject: Re: Unable to get SSL working on Tomcat 8.5
>>>
> Todd,
> 
> On 11/29/16 4:41 PM, Bartlett, Todd wrote:
> The below settings work fine on 6.0 version (no other changes Im
> aware
> of)  Error received Failed to initialize component
> [Connector[HTTP/1.1-443
> What's the rest of the error message?
> 
>  maxThreads="150" scheme="https" secure="true"
> keystoreFile="C:\.pfx" keystorePass=""
> keystoreType="pkcs12" clientAuth="false"
> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." />
> Looks okay so far. You need to post more information.
> 
> -chris
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Thread-safety of javax.servlet.Servlet#getServletConfig()

[Terence M. Bandoian]

On 12/5/2016 7:40 AM, Péter Gergely Horváth wrote:

Hi Chris,

Thanks your four input: this question is somewhere in-between... :)

We have *definitely* seen cases, where a piece of code like the one below
sometimes (a couple of times from tens of thousands of successfully
serviced requests) found the stored field to be null - with a
NullPointerException being thrown on the first access of the fooBarService
  field.

@WebServlet("/open")
public class FooBarServlet extends HttpServlet {

 private FooBarService fooBarService;
   @Override
 public void init() throws ServletException {
 try {
 ApplicationContext applicationContext =
 (ApplicationContext)
getServletContext().getAttribute("springContext");
 fooBarService =
 applicationContext.getBean("fooBarService",
FooBarService.class);

 } catch (Exception ex) {
 // wrap any exceptions to ServletException so as to comply with
Servlet contract
 throw new ServletException("Initialization failed with
exception", ex);



Does this exception ever occur?

-Terence Bandoian



 }
 }

 protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
 processRequest(request, response);
 }

 protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
 processRequest(request, response);
 }

 private void processRequest(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {

 List = fooBarService.getFooBars(); /// we have seen NPEs
thrown from here
/// ...
 }


For the first glance, it seemed to be obvious that it must have been a
threading issue, which could easily be solved by adding volatile to the
stored fooBarService field.

However, I was more than confused seeing
that javax.servlet.GenericServlet#config uses the same approach by simply
storing the ServletConfig into a field and reading it later on without any
locking etc.

I quickly scanned through the Servlet specs and Catalina codes, but cannot
really locate any explicit reference to thread-safety of
javax.servlet.GenericServlet#getServletConfig, that is where the question
originates.

I would by much obliged if you had any inputs, ideas regarding this, or on
the approach one could take to confirm it on his/her own.

Thanks,
Peter


On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Péter,

On 11/28/16 11:01 AM, Péter Gergely Horváth wrote:

Thank you very much for your feedback, but I think there is a
slight misunderstanding here: I know the order in which a servlet
is initialized and put into service, and this question is not
related to that. It's related to the _visibility_ of the field.

The question is about the thread safety of the field access: if
you carefully check the details of
javax.servlet.GenericServlet#config and compare the implementation
to the sample "NoVisibility" from the book Java Concurrency in
Practice, then it is seems to follow the same pattern, which is
"not thread-safe because the value field is accessed from both get
and set without synchronization. Among other hazards, it is
susceptible to stale values: if one thread calls set, other threads
calling get may or may not see that update." [1].

Personally, I would like to understand why this implementation is
not (if not) susceptible to the stale values phenomenon [2]; there
might be someone, who can point me to the right direction.

I think you are correct that there is a theoretical multi-threaded
race-condition, here. The container may initialize the servlet in one
thread and service e.g. the first request in another thread, and the
ServletContext reference might not be written to main memory and then
read-back by the request-processing thread.

Potential fixes for this would be either to define the ServletContext
member to be volatile or to use synchronized methods.'

Adding synchronization to the init() method would not be a problem at
all: there is very little monitor contention at that stage and the
container would only expect to call that method a single time. Adding
synchronization to the getServletContext method, though, might
represent a reduction in performance, since getServletContext gets
called many times during the lifetime of a Servlet, and from many thread
s.

Likewise, marking the ServletContext member as "volatile" would
necessarily require a slow main-memory read every time
getServletContext is called.

I suspect simple analysis above is the reason for no multithreaded
protection being placed on the ServletContext member in question.

Péter, is this an academic discussion, or have you in fact seen a case
where a servlet has been initialized and yet the first thread to
process a request receives a null 

AW: log4j2 configuration in Tomcat 8.5.8

[Frank.Pientka]

OK Rainer i moved log4j-core-2.6.2.jar, log4j-api-2.6.2.jar, 
log4j-jul-2.6.2.jar and log4j2.xml to $CATALINA_HOME/bin
Then changed
set 
JAVA_OPTS=-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
set LOGGING_CONFIG=-DnoOpp
set 
LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
set 
"CLASSPATH=.;%CATALINA_BASE%\bin;%CATALINA_BASE%\bin\log4j-core-2.6.2.jar;%CATALINA_BASE%\bin\log4j-api-2.6.2.jar;%CATALINA_BASE%\bin\log4j-jul-2.6.2.jar"
then all woked fine THX frank

-Ursprüngliche Nachricht-
Von: Rainer Jung [mailto:rainer.j...@kippdata.de] 
Gesendet: Montag, 5. Dezember 2016 12:28
An: Tomcat Users List 
Betreff: Re: log4j2 configuration in Tomcat 8.5.8

Am 05.12.2016 um 08:32 schrieb frank.pien...@materna.de:
> It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2.
> I put the following jars in $CATALINA_HOME/lib
> log4j 2 core (log4j-core-2.6.2.jar)
> log4j 2 api (log4j-api-2.6.2.jar) Delete the file 
> $CATALINA_HOME/conf/logging.properties
> Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib 
>   name="catalina" packages="">
> 
>  
> 
> 
>  fileName="${catalina.base}/logs/catalina.log">
>   
> %d %p %c{1.} [%t] %m%n
>   
> 
> 
>   
>
> 
>   
> 
>   
>  
> 
>   
> 
> No errors but the created catalina.out file is empty and the console 
> layout doesn't change What else to check or change?
> THX Frank

Currently you need to put three log4j2 jar files into the CLASSPATH (not the 
lib directory):

- core
- api
- jul bridge

Next put your log4j2.xml in some special directory and add that directory to 
the CLASSPATH as well.

Since in 8.5 Log4J integration is via its jul bridge it must be loadable by 
jul, that's why CLASSPATH and not just the lib directory.

Finally add the following system property to inform jul that it should log via 
log4j2:

-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

for instance by setting LOGGING_MANAGER to that value. To reduce confusion I 
suggest to also set LOGGING_CONFIG to some dummy value, e.g. 
-Dnop.

See:

http://logging.apache.org/log4j/2.x/log4j-jul/index.html

There is a (minor) flaw currently in this integration: the location info (class 
name, method name, line number) will be wrong and always point to a fixed 
position in Tomcat Juli instead of the "real" class calling the log method.

For more details about this problem see also:

http://marc.info/?t=14774015512=1=2

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Thread-safety of javax.servlet.Servlet#getServletConfig()

[Mark Thomas]

On 05/12/2016 13:40, Péter Gergely Horváth wrote:
> Hi Chris,
> 
> Thanks your four input: this question is somewhere in-between... :)
> 
> We have *definitely* seen cases, where a piece of code like the one below
> sometimes (a couple of times from tens of thousands of successfully
> serviced requests) found the stored field to be null - with a
> NullPointerException being thrown on the first access of the fooBarService
>  field.
> 
> @WebServlet("/open")
> public class FooBarServlet extends HttpServlet {
> 
> private FooBarService fooBarService;
>   @Override
> public void init() throws ServletException {
> try {
> ApplicationContext applicationContext =
> (ApplicationContext)
> getServletContext().getAttribute("springContext");
> fooBarService =
> applicationContext.getBean("fooBarService",
> FooBarService.class);
> 
> } catch (Exception ex) {
> // wrap any exceptions to ServletException so as to comply with
> Servlet contract
> throw new ServletException("Initialization failed with
> exception", ex);
> }
> }
> 
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> processRequest(request, response);
> }
> 
> protected void doPost(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> processRequest(request, response);
> }
> 
> private void processRequest(HttpServletRequest request,
> HttpServletResponse response) throws IOException, ServletException {
> 
> List = fooBarService.getFooBars(); /// we have seen NPEs
> thrown from here
> /// ...
> }
> 
> 
> For the first glance, it seemed to be obvious that it must have been a
> threading issue, which could easily be solved by adding volatile to the
> stored fooBarService field.
> 
> However, I was more than confused seeing
> that javax.servlet.GenericServlet#config uses the same approach by simply
> storing the ServletConfig into a field and reading it later on without any
> locking etc.
> 
> I quickly scanned through the Servlet specs and Catalina codes, but cannot
> really locate any explicit reference to thread-safety of
> javax.servlet.GenericServlet#getServletConfig, that is where the question
> originates.
> 
> I would by much obliged if you had any inputs, ideas regarding this, or on
> the approach one could take to confirm it on his/her own.

In theory, it is a problem.

In practise, I'd be surprised if anyone was ever troubled by it.

Since it appears you did hit this issue, open a bug report and we'll get
Tomcat's implementation fixed.

Mark


> 
> Thanks,
> Peter
> 
> 
> On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> Péter,
> 
> On 11/28/16 11:01 AM, Péter Gergely Horváth wrote:
 Thank you very much for your feedback, but I think there is a
 slight misunderstanding here: I know the order in which a servlet
 is initialized and put into service, and this question is not
 related to that. It's related to the _visibility_ of the field.

 The question is about the thread safety of the field access: if
 you carefully check the details of
 javax.servlet.GenericServlet#config and compare the implementation
 to the sample "NoVisibility" from the book Java Concurrency in
 Practice, then it is seems to follow the same pattern, which is
 "not thread-safe because the value field is accessed from both get
 and set without synchronization. Among other hazards, it is
 susceptible to stale values: if one thread calls set, other threads
 calling get may or may not see that update." [1].

 Personally, I would like to understand why this implementation is
 not (if not) susceptible to the stale values phenomenon [2]; there
 might be someone, who can point me to the right direction.
> 
> I think you are correct that there is a theoretical multi-threaded
> race-condition, here. The container may initialize the servlet in one
> thread and service e.g. the first request in another thread, and the
> ServletContext reference might not be written to main memory and then
> read-back by the request-processing thread.
> 
> Potential fixes for this would be either to define the ServletContext
> member to be volatile or to use synchronized methods.'
> 
> Adding synchronization to the init() method would not be a problem at
> all: there is very little monitor contention at that stage and the
> container would only expect to call that method a single time. Adding
> synchronization to the getServletContext method, though, might
> represent a reduction in performance, since getServletContext gets
> called many times during the lifetime of a Servlet, and from many thread
> s.
> 
> Likewise, marking the ServletContext member as "volatile" would
> necessarily require a slow 

Re: Thread-safety of javax.servlet.Servlet#getServletConfig()

[Péter Gergely Horváth]

Hi Chris,

Thanks your four input: this question is somewhere in-between... :)

We have *definitely* seen cases, where a piece of code like the one below
sometimes (a couple of times from tens of thousands of successfully
serviced requests) found the stored field to be null - with a
NullPointerException being thrown on the first access of the fooBarService
 field.

@WebServlet("/open")
public class FooBarServlet extends HttpServlet {

private FooBarService fooBarService;
  @Override
public void init() throws ServletException {
try {
ApplicationContext applicationContext =
(ApplicationContext)
getServletContext().getAttribute("springContext");
fooBarService =
applicationContext.getBean("fooBarService",
FooBarService.class);

} catch (Exception ex) {
// wrap any exceptions to ServletException so as to comply with
Servlet contract
throw new ServletException("Initialization failed with
exception", ex);
}
}

protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
processRequest(request, response);
}

protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
processRequest(request, response);
}

private void processRequest(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {

List = fooBarService.getFooBars(); /// we have seen NPEs
thrown from here
/// ...
}


For the first glance, it seemed to be obvious that it must have been a
threading issue, which could easily be solved by adding volatile to the
stored fooBarService field.

However, I was more than confused seeing
that javax.servlet.GenericServlet#config uses the same approach by simply
storing the ServletConfig into a field and reading it later on without any
locking etc.

I quickly scanned through the Servlet specs and Catalina codes, but cannot
really locate any explicit reference to thread-safety of
javax.servlet.GenericServlet#getServletConfig, that is where the question
originates.

I would by much obliged if you had any inputs, ideas regarding this, or on
the approach one could take to confirm it on his/her own.

Thanks,
Peter


On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Péter,
>
> On 11/28/16 11:01 AM, Péter Gergely Horváth wrote:
> > Thank you very much for your feedback, but I think there is a
> > slight misunderstanding here: I know the order in which a servlet
> > is initialized and put into service, and this question is not
> > related to that. It's related to the _visibility_ of the field.
> >
> > The question is about the thread safety of the field access: if
> > you carefully check the details of
> > javax.servlet.GenericServlet#config and compare the implementation
> > to the sample "NoVisibility" from the book Java Concurrency in
> > Practice, then it is seems to follow the same pattern, which is
> > "not thread-safe because the value field is accessed from both get
> > and set without synchronization. Among other hazards, it is
> > susceptible to stale values: if one thread calls set, other threads
> > calling get may or may not see that update." [1].
> >
> > Personally, I would like to understand why this implementation is
> > not (if not) susceptible to the stale values phenomenon [2]; there
> > might be someone, who can point me to the right direction.
>
> I think you are correct that there is a theoretical multi-threaded
> race-condition, here. The container may initialize the servlet in one
> thread and service e.g. the first request in another thread, and the
> ServletContext reference might not be written to main memory and then
> read-back by the request-processing thread.
>
> Potential fixes for this would be either to define the ServletContext
> member to be volatile or to use synchronized methods.'
>
> Adding synchronization to the init() method would not be a problem at
> all: there is very little monitor contention at that stage and the
> container would only expect to call that method a single time. Adding
> synchronization to the getServletContext method, though, might
> represent a reduction in performance, since getServletContext gets
> called many times during the lifetime of a Servlet, and from many thread
> s.
>
> Likewise, marking the ServletContext member as "volatile" would
> necessarily require a slow main-memory read every time
> getServletContext is called.
>
> I suspect simple analysis above is the reason for no multithreaded
> protection being placed on the ServletContext member in question.
>
> Péter, is this an academic discussion, or have you in fact seen a case
> where a servlet has been initialized and yet the first thread to
> process a request receives a null value 

Re: log4j2 configuration in Tomcat 8.5.8

[Rainer Jung]

Am 05.12.2016 um 08:32 schrieb frank.pien...@materna.de:

It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2.
I put the following jars in $CATALINA_HOME/lib
log4j 2 core (log4j-core-2.6.2.jar)
log4j 2 api (log4j-api-2.6.2.jar)
Delete the file $CATALINA_HOME/conf/logging.properties
Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib



 



  
%d %p %c{1.} [%t] %m%n
  


  
   

  

  
 

  

No errors but the created catalina.out file is empty and the console layout 
doesn't change
What else to check or change?
THX Frank


Currently you need to put three log4j2 jar files into the CLASSPATH (not 
the lib directory):


- core
- api
- jul bridge

Next put your log4j2.xml in some special directory and add that 
directory to the CLASSPATH as well.


Since in 8.5 Log4J integration is via its jul bridge it must be loadable 
by jul, that's why CLASSPATH and not just the lib directory.


Finally add the following system property to inform jul that it should 
log via log4j2:


-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

for instance by setting LOGGING_MANAGER to that value. To reduce 
confusion I suggest to also set LOGGING_CONFIG to some dummy value, e.g. 
-Dnop.


See:

http://logging.apache.org/log4j/2.x/log4j-jul/index.html

There is a (minor) flaw currently in this integration: the location info 
(class name, method name, line number) will be wrong and always point to 
a fixed position in Tomcat Juli instead of the "real" class calling the 
log method.


For more details about this problem see also:

http://marc.info/?t=14774015512=1=2

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Two Way SSL - SSL Offloading at load balancer

[Macca, Diego]

Hi all,
Probably the FW can be configured to not terminate the SSL connection. It 
should act as a pass-through.

But since few months we noticed that Tomcat is not requesting the client 
certificate anymore (Tomcat to Tomcat, the browsers always receive a 
certificate request). It complete the handshake so the SSL communication is 
established but no certificate is sent.  If I got this right is because 
something has been changed in a later revision in Java 8.
To force Tomcat to request the client certificate we had to set clientAuth to 
true.

Just my 2 cents.

Kind Regards,

Diego Macca
Senior IT Specialist

DG-IS/EDA - Executional Domain Applications
EUROPEAN CENTRAL BANK
Tel.: +49 (69) 1344 6991
E-mail: diego.ma...@ecb.europa.eu
www.ecb.europa.eu
www.youtube.com/ecbeuro
https://twitter.com/ecb

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 02 December 2016 17:09
To: Tomcat Users List
Subject: Re: Two Way SSL - SSL Offloading at load balancer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bipin,

On 12/2/16 7:27 AM, Bipin Jethwani wrote:
> We use Spring security and want to use Two Way SSL for a few Jersey
> based REST APIs exposed for mobile devices. SSL is offloaded at
> load-balancer or apache level.
>
> Can we still get access to client certificate at web app level?

That depends.

How are you connecting your load-balancer to Tomcat. Can you configure the 
load-balancer to forward the TLS details to Tomcat? With httpd, both mod_jk and 
mod_proxy_ajp can do it natively. Using mod_proxy_httpd, you just have to make 
sure that the certificates are forwarded as HTTP request headers, and you'll 
need to configure the RemoteIPValve to unpack that information and put it into 
the HttpServletRequest object in a place your application might expect it to be.

> On second thought we can live without having access to client cert but
> can we have load-balancer or apache configured to request for client
> cert only for a specific urls?

No. Only the component terminating TLS can request a certificate from the 
client. If there is a way for you to signal to the load-balancer that you want 
to request a certificate, then the load-balancer can request a TLS 
renegotiation and ask for a client certificate at that point.

> Is there a standard for this?

None that I know of.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYQZySAAoJEBzwKT+lPKRYD3kP/00panFQA1oqLeU6NvAySvwc
gHyxLLt4PKSRJrlrczk/ftw8czjepDQx3Z4Rk4bQ3x4EwFNcqv+DnvfBuRv0f3W8
15fzIQhRcULvkdhJ+AHWW73y3wsoRl0U1f6nAAma6nevZgbmXy3efUIWeIFZy7RY
o8qLBfTy5krcPft9GMMEjGVtkWOB54NFoRe3Sp8iE1CR3jw8oGyzE2i3WdJKhsxE
iFoJcnNJH65sBKwL2LtpahgaZ6YeRGa7SLcYgTkcldyfqEEd1zZYlBQTZFQh6Zy0
BEUTWz99r5klMaU0Zn7QiYfFrWkA0pF4agdFnsWElj2ZsJ2YAC+ckAsZ7Rj2oHwD
s4ehb6zCGeTE/bToD4nlb1iizZuWTIlFCzhZ3d/iYNHVCnICOdt0IyPAV/cVl9iL
r9htFbB6hzd05ALP5MfLzqluhP5sGhuKhBK5glda3prLP2L7b14IxbfuOGTYbgPV
q7fTfLfim7veQYpZWoRIdUjqkQM9BN43AkX3HyGF15SirL9U0NEXQkiipHR0Fi3E
FR3JmDcsphMV+bvHnzHeVbMEzNrai1GZhZ6Y+6IW2iRGwgWcfO4nCU10ZPGDh50H
2sW0R27nZviNHocLGgSJsmGFO98rrUHlHYXpPCn+NTFAF+zwE0S5d6qf5RFKtGWr
8xiy+1gtF7s/tSQhVlap
=83a5
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Any e-mail message from the European Central Bank (ECB) is sent in good faith, 
but shall neither be binding nor construed as constituting a commitment by the 
ECB except where provided for in a written agreement. This e-mail is intended 
only for the use of the recipient(s) named above. Any unauthorised disclosure, 
use or dissemination, either in whole or in part, is prohibited. If you have 
received this e-mail in error, please notify the sender immediately via e-mail 
and delete this e-mail from your system. The ECB processes personal data in 
line with Regulation (EC) No 45/2001 and Decision ECB/2007/1. For any further 
information you can consult the Data Protection Disclaimer on the ECB webpage. 
In case of queries, please contact the ECB Data Protection Officer 
(d...@ecb.europa.eu). You may also contact the European Data Protection 
Supervisor.