Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[Peter Kreuser]

James,

> Am 07.01.2021 um 00:34 schrieb James H. H. Lampert :
> 
> We just had our first Tomcat 8.5 installation on a customer's AS/400.
> 
> The customer apparently has his own CA (they're a big company), and when I 
> installed SSL in their Tomcat, and tested it with a browser, it complained, 
> something to the general effect of "weak signature algorithm."
> 
I guess they never upgraded their CA and still sign the certs with SHA1 or even 
MD5.

They should change that for sure!

Peter

> While it's not really my problem (and is only connected to Tomcat by virtue 
> of it happening with a Tomcat server), I'm curious about what's up with it, 
> if anybody here is able and willing to explain it.
> 
> Of course, a customer that's big enough to run a private CA in production is 
> already doing things beyond my pay grade.
> 
> --
> JHHL
> 
> -
> 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: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[James H. H. Lampert]

On 1/6/21 3:46 PM, Robert Turner wrote:

You'll want to set the protocols, ciphers, and honorCipherOrder ...


The precise wording in the error message is:

. . . but the server presented a certificate signed using a weak
signature algorithm (such as SHA-1). . . .


Which is to say, it doesn't sound like a cipher or protocol problem, or 
anything else that's actually under Tomcat's control.


But I figured somebody here might know something about it.

--
JHHL

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

Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[Robert Turner]

You'll want to set the protocols, ciphers, and honorCipherOrder attributes
on either the Connector or the SSLHostConfig objects in your server.xml
file to restrict the available TLS/SSL protocols and ciphers available to
avoid using weak ones.

See the documentation here for details:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support

For example (please pick TLS levels and ciphers for your application --
this may not suit your requirements):














On Wed, Jan 6, 2021 at 6:34 PM James H. H. Lampert 
wrote:

> We just had our first Tomcat 8.5 installation on a customer's AS/400.
>
> The customer apparently has his own CA (they're a big company), and when
> I installed SSL in their Tomcat, and tested it with a browser, it
> complained, something to the general effect of "weak signature algorithm."
>
> While it's not really my problem (and is only connected to Tomcat by
> virtue of it happening with a Tomcat server), I'm curious about what's
> up with it, if anybody here is able and willing to explain it.
>
> Of course, a customer that's big enough to run a private CA in
> production is already doing things beyond my pay grade.
>
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[James H. H. Lampert]

We just had our first Tomcat 8.5 installation on a customer's AS/400.

The customer apparently has his own CA (they're a big company), and when 
I installed SSL in their Tomcat, and tested it with a browser, it 
complained, something to the general effect of "weak signature algorithm."


While it's not really my problem (and is only connected to Tomcat by 
virtue of it happening with a Tomcat server), I'm curious about what's 
up with it, if anybody here is able and willing to explain it.


Of course, a customer that's big enough to run a private CA in 
production is already doing things beyond my pay grade.


--
JHHL

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

Parallel deploy with /manager/text servlet

[Manuel Dominguez Sarmiento]

Hi, our system consists on about 80+ webapps on different servers. 
Multiple webapps are deployed per Tomcat server remotely using the 
manager and host-manager webapps.


This has been working fine for years, however some servers now have 5+ 
webapps and they are taking a long time to start. We invoke the deploy 
command on the manager webapp in parallel for each webapp, in order to 
attempt a reduction in total server startup time. However the speedup is 
very modest. The servers have powerful Xeon multi-core servers so a 
parallel speedup should be possible.


Looking at the source code for 
org.apache.catalina.manager.ManagerServlet we see that the following 
method is synchronized which would explain the behaviour we are seeing:

    protected synchronized void deploy
    (PrintWriter writer, String config, ContextName cn,
 String tag, boolean update, HttpServletRequest request,
 StringManager smClient) {

Is there any real reason why this needs to be synchronized? Tomcat can 
deploy webapps in parallel when backgroundProcessorDelay is set to a 
positive number, but this is not useful when remotely deploying webapps 
using the manager webapp.


Any ideas? Thanks

*Manuel Dominguez Sarmiento*

Re: Request body is empty in Tomcat 9.0.38

[Mounika Reddy]

If you can see the WSDL for the service assuming its a SOAP, then you can
actually generate a sample client XML using SOAP GUI clients and verify if
the service is actually deployed correctly

On Wed, Jan 6, 2021, 7:59 AM Mounika Reddy  wrote:

> Check if it's a malformed XML and namespaces qualified are right. If JSON
> it's a different issue and without much info, I hardly think it's a tomcat
> issue
>
> On Wed, Jan 6, 2021, 7:51 AM Jonnalagadda, Swathi (External) <
> swathi.jonnalaga...@xerox.com> wrote:
>
>> Hi
>>
>> We have a web application deployed in tomcat9.0.38 which is invoking a
>> web service which is again deployed in another tomcat instance of 9.0.38
>>
>> We are using httpclient to post request to webservice from the
>> webapplication  and we could see that the request is reaching the
>> webservice instance but the request body is all empty due to which the
>> webservice is not able to read the request from client.
>>
>> Could you please suggest if there is any configuration missing out here.
>>
>> Thanks
>> Swathi
>>
>

Re: Request body is empty in Tomcat 9.0.38

[Mounika Reddy]

Check if it's a malformed XML and namespaces qualified are right. If JSON
it's a different issue and without much info, I hardly think it's a tomcat
issue

On Wed, Jan 6, 2021, 7:51 AM Jonnalagadda, Swathi (External) <
swathi.jonnalaga...@xerox.com> wrote:

> Hi
>
> We have a web application deployed in tomcat9.0.38 which is invoking a web
> service which is again deployed in another tomcat instance of 9.0.38
>
> We are using httpclient to post request to webservice from the
> webapplication  and we could see that the request is reaching the
> webservice instance but the request body is all empty due to which the
> webservice is not able to read the request from client.
>
> Could you please suggest if there is any configuration missing out here.
>
> Thanks
> Swathi
>

Request body is empty in Tomcat 9.0.38

[Jonnalagadda, Swathi (External)]

Hi

We have a web application deployed in tomcat9.0.38 which is invoking a web 
service which is again deployed in another tomcat instance of 9.0.38

We are using httpclient to post request to webservice from the webapplication  
and we could see that the request is reaching the webservice instance but the 
request body is all empty due to which the webservice is not able to read the 
request from client.

Could you please suggest if there is any configuration missing out here.

Thanks
Swathi

Re: Not able to make JSESSIONID cookie secure

[Martin Grigorov]

Hi Amit,

On Wed, Jan 6, 2021 at 11:15 AM Amit Khosla 
wrote:

> Hi,
>
> Thanks for the reply.
>
> We tried the settings on multiple machines. And found that the same
> configuration machines gave different results.
> We are getting multiple jsessionid cookies being created. In our
> application, we have a multi tenant application.
> For each tenant we have an nginx running calling the application url.
> URL being hit on browser is like
> *.myapp.com *
> We are able to see 2 JSESSIONID cookies being generated for this call on
> some machines.
> 1. domain: /myapp  which is having secure flag.
> 2. domain: /myapp/ which is NOT having secure flag.
>
> Strangely, in most machines, we are finding the second cookie being
> generated but the first cookie not generated.
> Only when we saw on one of the machines, the first cookie, we found that
> the secure jsessionid cookie being generated on that particular
> environment.
>
> The environment having 2 cookies and the one with one cookie are identical.
> Can you please help me fix the creation of the second cookie and also how
> to ensure that the first cookie is generated in all environments?
>

I think you issue is in Nginx config.
Please test first only with Tomcat and see whether it behaves propertly.
If it does then ask for more help at Nginx forums.
If it doesn't then please explain in more details how exactly you test it,
with configs, urls, etc.


>
>
> On Tue, Jan 5, 2021 at 1:24 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Mark,
> >
> > On 1/4/21 03:17, Mark Thomas wrote:
> > > On 04/01/2021 06:02, Amit Khosla wrote:
> > >> Hi,
> > >>
> > >> We are still facing this issue. Can someone please help us?
> > >
> > > In a clean 8.5.x install, session cookies are only marked as secure if
> > > the request that triggered the session creation is made over a secure
> > > channel (typically HTTPS).
> > >
> > > If you amend the session configuration in $CATALINA_BASE/conf/web.xml
> > from:
> > >
> > > 
> > >  30
> > > 
> > >
> > > to
> > >
> > > 
> > >  30
> > >  
> > >  true
> > >  
> > > 
> > >
> > > then session cookies will be generated with the secure flag whether or
> > > not the request that triggered the the session creation was made over a
> > > secure channel.
> > >
> > > Reviewing the thread:
> > >
> > > Are you sure you are amending the correct web.xml file? One way to
> check
> > > this is to make a deliberate error in the file and confirm that this
> > > error is reported when Tomcat starts.
> > >
> > > Note that you can only use  once in a web.xml file. If
> > > the web.xml file already contains a  element you must
> > > add to that existing element.
> > >
> > > Configuration in the application's web.xml file will override the
> global
> > > web.xml file. Make sure that the application's web.xml either does not
> > > specify a value for secure or specifies true.
> > >
> > > If you still have issues:
> > > - start with a clean Tomcat 8.5.x install
> > > - confirm that
> > >http://localhost:8080/examples/servlets/servlet/SessionExample
> > >generates a set-cookie header without the secure attribute
> > > - stop Tomcat
> > > - close the browser
> > > - amend conf/web.xml as above
> > > - start Tomcat
> > > - confirm that
> > >http://localhost:8080/examples/servlets/servlet/SessionExample
> > >generates a set-cookie header with the secure attribute
> > > - retest with your application
> > >
> > > You must close the browser between each request you expect to generate
> a
> > > session cookie to prevent any existing session from being used.
> >
> > You may be able to avoid this with either of:
> >
> > 1. "Private" browsing mode: use a new "private" tab/window each time
> >
> > 2. Under developer tools / Storage (you may have to poke around for
> > this), you should be able to see the cookies for the host and, if
> > appropriate, delete them.
> >
> > > If this test fails then you'll need to check the application source
> > > code. It is possible that the application is overriding your attempts
> to
> > > make the session cookie secure.
> >
> > +1
> >
> > Other possibilities include a reverse proxy where the client is using
> > HTTPS to communicate with the proxy, but HTTPS is not being used between
> > the proxy and the Tomcat server.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
> Thanks & Regards
> Amit Khosla
>

Re: Not able to make JSESSIONID cookie secure

[Amit Khosla]

Hi,

Thanks for the reply.

We tried the settings on multiple machines. And found that the same
configuration machines gave different results.
We are getting multiple jsessionid cookies being created. In our
application, we have a multi tenant application.
For each tenant we have an nginx running calling the application url.
URL being hit on browser is like
*.myapp.com *
We are able to see 2 JSESSIONID cookies being generated for this call on
some machines.
1. domain: /myapp  which is having secure flag.
2. domain: /myapp/ which is NOT having secure flag.

Strangely, in most machines, we are finding the second cookie being
generated but the first cookie not generated.
Only when we saw on one of the machines, the first cookie, we found that
the secure jsessionid cookie being generated on that particular environment.

The environment having 2 cookies and the one with one cookie are identical.
Can you please help me fix the creation of the second cookie and also how
to ensure that the first cookie is generated in all environments?


On Tue, Jan 5, 2021 at 1:24 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mark,
>
> On 1/4/21 03:17, Mark Thomas wrote:
> > On 04/01/2021 06:02, Amit Khosla wrote:
> >> Hi,
> >>
> >> We are still facing this issue. Can someone please help us?
> >
> > In a clean 8.5.x install, session cookies are only marked as secure if
> > the request that triggered the session creation is made over a secure
> > channel (typically HTTPS).
> >
> > If you amend the session configuration in $CATALINA_BASE/conf/web.xml
> from:
> >
> > 
> >  30
> > 
> >
> > to
> >
> > 
> >  30
> >  
> >  true
> >  
> > 
> >
> > then session cookies will be generated with the secure flag whether or
> > not the request that triggered the the session creation was made over a
> > secure channel.
> >
> > Reviewing the thread:
> >
> > Are you sure you are amending the correct web.xml file? One way to check
> > this is to make a deliberate error in the file and confirm that this
> > error is reported when Tomcat starts.
> >
> > Note that you can only use  once in a web.xml file. If
> > the web.xml file already contains a  element you must
> > add to that existing element.
> >
> > Configuration in the application's web.xml file will override the global
> > web.xml file. Make sure that the application's web.xml either does not
> > specify a value for secure or specifies true.
> >
> > If you still have issues:
> > - start with a clean Tomcat 8.5.x install
> > - confirm that
> >http://localhost:8080/examples/servlets/servlet/SessionExample
> >generates a set-cookie header without the secure attribute
> > - stop Tomcat
> > - close the browser
> > - amend conf/web.xml as above
> > - start Tomcat
> > - confirm that
> >http://localhost:8080/examples/servlets/servlet/SessionExample
> >generates a set-cookie header with the secure attribute
> > - retest with your application
> >
> > You must close the browser between each request you expect to generate a
> > session cookie to prevent any existing session from being used.
>
> You may be able to avoid this with either of:
>
> 1. "Private" browsing mode: use a new "private" tab/window each time
>
> 2. Under developer tools / Storage (you may have to poke around for
> this), you should be able to see the cookies for the host and, if
> appropriate, delete them.
>
> > If this test fails then you'll need to check the application source
> > code. It is possible that the application is overriding your attempts to
> > make the session cookie secure.
>
> +1
>
> Other possibilities include a reverse proxy where the client is using
> HTTPS to communicate with the proxy, but HTTPS is not being used between
> the proxy and the Tomcat server.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Thanks & Regards
Amit Khosla