Re: mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-11 Thread Wayne Li
> Probably the quickest : download these files, install them on your
server, and change the above links.
Like : create a sub-directory "/js" of your webapp, and install them there.
Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"

Yes. It works. Thanks.

It is okay for now. but, if I do not want host these files, what should I
do? Can you point a direction for me please?

On Mon, Jul 11, 2016 at 12:38 PM, André Warnier (tomcat) 
wrote:

> On 11.07.2016 19:38, Wayne Li wrote:
>
>> Thank you for quick reply.
>> Thank you for suggest LiveHTTPHeaders for firefox. I just tried. Good. It
>> says that the file was loaded. So I think the problems are in the lines
>> of:
>>
>>http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.css"/>
>>http://code.jquery.com/jquery-1.11.3.min.js";>
>>http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.js";>
>>
>> These lines could not be forwarded under ssl? What should I do?
>> Thanks.
>>
>
> Probably the quickest : download these files, install them on your server,
> and change the above links.
> Like : create a sub-directory "/js" of your webapp, and install them there.
> Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"
>
>
>>
>> On Mon, Jul 11, 2016 at 9:28 AM, André Warnier (tomcat) 
>> wrote:
>>
>> On 11.07.2016 15:57, Wayne Li wrote:
>>>
>>> Hi All,


 Hi. Thanks you for communicating the versions and the configuration
>>> below..
>>> That helps a lot in helping you.
>>>
>>> Can you also provide the version of the mod_jk module ? It should be in
>>> the first line of the Apache httpd error log (when it starts up).
>>>
>>> I have a servlet/jsp application running on tomcat 7.0.47. There are no
>>>
 static html files.
 Now I am try to use apache 2.4.7 (Ubuntu)
 as the front and forwad eveything to tomcat. I installed mod_jk using
 Ubuntu's software
 center.. Things are working: I type "localhost" on my brower bar, it
 shows
 my application.

 Then, I also trying to use ssl and generated self-signed certificate. It
 works, because
 the browser warns me about unknown certificate. If I type "
 https://www.mytest.com/index.jsp;
 on the browser's bar, it shows the page. But not correctly: the page
 contains:
   
   
 These extra files are not be called.


>>> Sorry to ask, but *are* these files present, in the same directory as
>>> your
>>> index.jsp page ?
>>>
>>>
>>> What is wrong on my side? Any information would be appreciated. Thank you
>>>
 in advance.


>>> There is some configuration information missing below : in
>>> /etc/apache2/mods-available, there should be a couple of files : jk.load
>>> and jk.conf.
>>> What is the content of these files ?
>>>
>>>
>>> the /etc/apache2/conf/default-ssl.conf:
 
   
 SSLEngine on
 SSLCertificateFile /etc/apache2/ssl/server.crt
 SSLCertificateFile /etc/apache2/ssl/server.crt


>>> above, duplicate lines ?
>>>
>>>
>>> JkMount /* ajp13_worker
>>>
   
 

 the /etc/apache2/conf/000-default.conf:
 
 ServerName localhost
 DocumentRoot /ROOT
 JkMountCopy On
 
   JkMount jk-status
   Order deny,allow
   Allow from 127.0.0.1,localhost
 
 
   JkMount jk-manager
   Order deny,allow
   Allow from 127.0.0.1,localhost
  
 

 the /etc/apache2/workers/worker.properties:
 workers.tomcat_home=/tomcat
 workers.java_home=/jdk8
 ps=/
 worker.list=ajp13_worker
 worker.ajp13_worker.port=8009
 worker.ajp13_worker.host=localhost
 worker.ajp13_worker.type=ajp13
 worker.ajp13_worker.lbfactor=1
 worker.loadbalancer.type=lb
 worker.loadbalancer.balance_workers=ajp13_worker
 worker.list=jk-status
 worker.jk-status.type=status
 worker.jk-status.read_only=true
 worker.list=jk-manager
 worker.jk-manager.type=status


 That workers.properties looks old, and contains some deprecated lines :
>>>
 workers.tomcat_home=/tomcat
 workers.java_home=/jdk8

>>>
>>> Also, you do not have a load-balancing setup, so I suggest to simplify
>>> the
>>> above and just have the following in worker.properties :
>>>
>>> worker.list=ajp13_worker
 worker.ajp13_worker.port=8009
 worker.ajp13_worker.host=localhost
 worker.ajp13_worker.type=ajp13

>>>
>>> You can find this here :
>>> http://tomcat.apache.org/connectors-doc/common_howto/quick.html
>>> -> Minimum workers.properties
>>>
>>> If you need the rest, you can re-add it later.
>>>
>>> Another recommendation : use the browser feature (or plugin or add-on)
>>> that allows you to see the exact dialog between the browser and 

Re: Need help setting up SSL on Tomcat 8

2016-07-11 Thread Ognjen Blagojevic

On 11.7.2016 16:29, Sean Son wrote:

Here is the certificate path:

- Go Daddy Root Certificate Authority - G2
   - Go Daddy Secure Certificate Authority - G2
  - *.example.com 



That looks Ok.

Did you, perhaps, tried to access server on subdomain of example.com? 
Wildcard certificate "*.example.com" is valid for "www.example.com", but 
not for "www.department.example.com".


-Ognjen



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



Re: Encoding issues with Tomcat 7.0.69+ and 8.0.33+

2016-07-11 Thread Mark Thomas
On 10/07/2016 22:24, Vincent Massol wrote:
> Ok I’ve found the issue that is causing the problem:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59317
> 
> Specifically it says:
> 
> “
> Async and non-async behaviours are currently the same.
>   • Both expect the path used to obtain the dispatcher to be decoded. 
> This behavior was confirmed with the Servlet EG.
>   • Both return the unencoded URI for req.getRequestURI(). That strikes 
> me as wrong.
> "
> 
> And
> 
> “
> The restriction the the request dispatcher (or the async dispatch) must be 
> obtained with a decoded path has not changed. However, I have applied a fix 
> that ensures that the result of the call to getRequestURI() after the 
> dispatch returned an encoded URI.
> “
> 
> It would be nice to have more information about " This behavior was confirmed 
> with the Servlet EG.". The Servlet spec doesn't mention anything and this 
> makes Tomcat have a different behavior than other servlet containers (Jetty 
> for example).
> 
> I believe this change is dangerous and is going to cause regression to lots 
> of applications out there who used to work with an encoded dispatcher path 
> and that are now going to not work anymore (as is the case with XWiki, see 
> http://jira.xwiki.org/browse/XWIKI-13556).
> 
> Could someone from the Tomcat dev team please comment on this?

This is the change in question (note the corrected version numbers):

Tomcat 8.0.x for 8.0.34 onwards:
http://svn.apache.org/viewvc?view=revision=1741019

Tomcat 7.0.x for 7.0.70 onwards:
http://svn.apache.org/viewvc?view=revision=1741024

This change ensured that a call to HttpServletRequest.getRequestURI()
returned an encoded URL rather than a decoded one if called from within
a dispatched request. The Javadoc for getRequestURI() is clear that the
returned value is not decoded so I am confident that this change was
correct.

Tomcat has required that a decoded path is used to obtain a
RequestDispatcher for as long as I can remember. I went back through svn
and this dates back to at least Tomcat 4.1.x.

Jetty (confirmed with 9.3.10) decodes the path provided to the
RequestDispather.

The Servlet spec has never been clear on which paths are encoded and
which are decoded. I have been trying to get this fixed for a number of
years (e.g. [1]) but unfortunately, the way Oracle runs the Servlet EG
the only changes that are made to the spec are the ones Oracle wants to
make.

The clarification from the EG (linked from a related bug report, [2])
the was more around the behaviour of AsyncContext.dispatch(). It implied
paths used with a RequestDispatcher were decoded but was not explicit.

Having spent a fair chunk of today thinking about this, I'm leaning
towards Tomcat being wrong not to decode the paths passed to the
RequestDispatcher. My reasoning is as follows:

Section 9.1.1 of the Servlet spec includes this example:

String path = “/raisins.jsp?orderno=5”;
RequestDispatcher rd = context.getRequestDispatcher(path);
rd.include(request, response);


It is clear from that example and the surrounding text that a query
string can be provided with the path. What if the JSP was called
"foo?bar.jsp" ? It is an odd name for a JSP but not an invalid one and
names like this are often useful for exploring edge cases. The only way
to dispatch to that JSP is to encode the '?' character. Therefore, the
RD is going to have to decode the path.

The above argument suggests that Tomcat has been handling requests for a
RequestDispatcher incorrectly for quite some time. I worry that changing
this behaviour might break something. On the other hand, if Jetty has
been decoding this path and an incompatibility has not been raised until
now, that suggests that the likelihood of breakage is lower.

I'll start a discussion on the dev list.

Mark


[1] https://java.net/jira/browse/SERVLET_SPEC-18
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=57559

> 
> Thanks
> -Vincent
> 
> 
>> On 08 Jul 2016, at 22:00, Vincent Massol  wrote:
>>
>> Hi guys,
>>
>> I work on the XWiki project (http://xwiki.org) and we’ve had several reports 
>> of users telling us that XWiki is not working anymore with versions of 
>> Tomcat > 7.0.69 and > 8.0.33. It works perfectly well with those versions 
>> and lower.
>>
>> The issue is described in more detail at 
>> http://jira.xwiki.org/browse/XWIKI-13556
>>
>> In short, I’ve tracked down one of the issues and here’s the problem we have:
>>
>> * We use context.getRequest().getRequestDispatcher(path).forward(…).
>> * We are url-encoding the path. For example:path =  
>> /bin/view/Main/test%20with%20space
>> * With Tomcat > 7.0.69 and > 8.0.33 (I’m testing with versions 8.0.36 and 
>> 7.0.59 to be precise) this generates an incoming URL of 
>> .../bin/view/Main/test%2520with%2520space in our code
>> * With Tomcat <= 7.0.69 and <= 8.0.33 it was generating an incoming URL of 
>> .../bin/view/Main/test%20with%20space in our code
>>
>> Also note that with 

Re: Configuring Tomcat to support TLSv1.2

2016-07-11 Thread Joleen Barker
Hello All,

I wanted to get back to you on this issue since working with the vendor.
Updating the SSL_VERSION parm was the correct thing to do in this case for
this product but it did not have an affect on the outgoing communications
when the application was acting at the client. There was no built in way to
set the product to use TLSv1.2 when  reaching out to the remote server. It
always used TLSv1.0 unless I had only TLSv1.2 defined in the SSL_VERSION
which we would not want to do as then we would loss the ability to support
those connecting to use using TLSv1.0 or 1.1. So it is really the way the
application is coded that caused the issue. I am waiting now for a defect
fix from the vendor. The fix will allow us to specifically program a
specific TLS version if a customer has a requirement to only allow a
specific one so it will not automatically use TLSv1.0.

Let me know if you have any questions and I will try my best to answer.

Thanks for the help again.

Joleen

On Fri, Jun 24, 2016 at 5:04 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 6/24/16 3:42 PM, Daniel Savard wrote:
> > 2016-06-24 11:50 GMT-04:00 Joleen Barker
> > :
> >
> >> Hi Chris,
> >>
> >> The SSL_VERSION parameter was already defined by the vendor.
> >>
> >>
> > I still would delete the SSL_VERSION from the catalina.sh or
> > comment it at least and adopt the suggested approach to configure
> > everything in the server.xml file instead.
>
> I believe the SSL_VERSION isn't affecting the configuration of the
> server at all, but the application's client configuration (in its role
> as a proxy).
>
> > Without a specific definition of the SSL_VERSION, there will be no
> > constraints on the versions at this point. This SSL_VERSION
> > environment variable will bite you when you will need to upgrade
> > Tomcat to another version.
> >
> >
> >> The web application we use allows users to connect to it via FTP,
> >> FTPS, SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to
> >> different back end servers. The web application is a proxy.
> >>
> >> Without me making the change to the predefined SSL_VERSION
> >> parameter that was originally configured as
> >> "-Dhttps.protocols=TLSv1" to now be configured to
> >> "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for
> >> correcting my typo) our remote party that uses and AS2 client
> >> that is locked down to only using TLSv1.2 connection could now
> >> connect to us successfully and upload a file. So with this change
> >> I was able to accomplish the client to connect to the Tomcat
> >> server. But I am unable to accomplish a successful connection
> >> when Tomcat is acting as the client to reach the remote AS2
> >> server for us to send a file to them. It appears we are not
> >> connecting to them using TLSv1.2 and therefore we are dropped. I
> >> have a ticket open with the vendor on this but they don't seem to
> >> be any help. I was trying to open the Java console on the UNIX
> >> server but I am unable to as I do not have any X11 setup. I am
> >> unable to find a command line option to set what is allowed in
> >> the Java application itself. On one of our test servers a
> >> colleague could open the console and we saw that none of the TLS
> >> options were NOT enabled and only SSLv3 was. I am not sure if
> >> this is the case with this server that I am working on that we
> >> have an outside connection open to be able to work with the
> >> outside customer.  I am unsure if this change would allow us to
> >> reach them. I didn't know what the catalina.sh TLSv1.2 change
> >> versus changing the Java application TLSv1.2 change is really
> >> responsible for. (I know enough to brake stuff...lol) The vendor
> >> is not much help. It's very frustrating so I reach out to this
> >> community and get the help I need.
> >>
> >>
> > The connection that isn't working is initiated by the web
> > application on your Tomcat server as far as I understand. If so,
> > then there is no configuration at the Tomcat level that will
> > resolve this issue. You must look at the SSL debugging info to see
> > what is going on in the negotiation with the remote party. To do
> > that, use the -Djavax.net.debug=ssl option to the JVM and look at
> > the log files (probably catalina.out) You should see the
> > handshaking protocol negotiation.
>
> +1
>
> Or, if possible, have a look at the application's code to see how it's
> configuring itself. Many components that give access to TLS don't
> provide a way to configure it (grr) so it's possible that system
> properties are the only way to go.
>
> > Perhaps your application is not sending a valid certificate or no
> > certificate at all or something like that, which then has nothing
> > to do with the inability to perform a full TLSv1.2 handshaking
> > procedure. Is this connection worked previously using a less secure
> > protocol?
> >
> >
> >> 

Re: mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-11 Thread tomcat

On 11.07.2016 19:38, Wayne Li wrote:

Thank you for quick reply.
Thank you for suggest LiveHTTPHeaders for firefox. I just tried. Good. It
says that the file was loaded. So I think the problems are in the lines of:

   http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.css"/>
   http://code.jquery.com/jquery-1.11.3.min.js";>
   http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.js";>

These lines could not be forwarded under ssl? What should I do?
Thanks.


Probably the quickest : download these files, install them on your server, and change the 
above links.

Like : create a sub-directory "/js" of your webapp, and install them there.
Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"




On Mon, Jul 11, 2016 at 9:28 AM, André Warnier (tomcat) 
wrote:


On 11.07.2016 15:57, Wayne Li wrote:


Hi All,



Hi. Thanks you for communicating the versions and the configuration below..
That helps a lot in helping you.

Can you also provide the version of the mod_jk module ? It should be in
the first line of the Apache httpd error log (when it starts up).

I have a servlet/jsp application running on tomcat 7.0.47. There are no

static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forwad eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working: I type "localhost" on my brower bar, it shows
my application.

Then, I also trying to use ssl and generated self-signed certificate. It
works, because
the browser warns me about unknown certificate. If I type "
https://www.mytest.com/index.jsp;
on the browser's bar, it shows the page. But not correctly: the page
contains:
  
  
These extra files are not be called.



Sorry to ask, but *are* these files present, in the same directory as your
index.jsp page ?


What is wrong on my side? Any information would be appreciated. Thank you

in advance.



There is some configuration information missing below : in
/etc/apache2/mods-available, there should be a couple of files : jk.load
and jk.conf.
What is the content of these files ?



the /etc/apache2/conf/default-ssl.conf:

  
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateFile /etc/apache2/ssl/server.crt



above, duplicate lines ?


JkMount /* ajp13_worker

  


the /etc/apache2/conf/000-default.conf:

ServerName localhost
DocumentRoot /ROOT
JkMountCopy On

  JkMount jk-status
  Order deny,allow
  Allow from 127.0.0.1,localhost


  JkMount jk-manager
  Order deny,allow
  Allow from 127.0.0.1,localhost
 


the /etc/apache2/workers/worker.properties:
workers.tomcat_home=/tomcat
workers.java_home=/jdk8
ps=/
worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=ajp13_worker
worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.list=jk-manager
worker.jk-manager.type=status



That workers.properties looks old, and contains some deprecated lines :

workers.tomcat_home=/tomcat
workers.java_home=/jdk8


Also, you do not have a load-balancing setup, so I suggest to simplify the
above and just have the following in worker.properties :


worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13


You can find this here :
http://tomcat.apache.org/connectors-doc/common_howto/quick.html
-> Minimum workers.properties

If you need the rest, you can re-add it later.

Another recommendation : use the browser feature (or plugin or add-on)
that allows you to see the exact dialog between the browser and the server
(HTTP requests, HTTP responses, status codes, HTTP headers etc.). That will
immensely simplify the debugging work.
For example, in Mozilla Firefox I use "LiveHTTPHeaders",
and with IE, I use "Fiddler2".




-
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: mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-11 Thread Wayne Li
Thank you for quick reply.
Thank you for suggest LiveHTTPHeaders for firefox. I just tried. Good. It
says that the file was loaded. So I think the problems are in the lines of:

  http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.css"/>
  http://code.jquery.com/jquery-1.11.3.min.js";>
  http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.js";>

These lines could not be forwarded under ssl? What should I do?
Thanks.


On Mon, Jul 11, 2016 at 9:28 AM, André Warnier (tomcat) 
wrote:

> On 11.07.2016 15:57, Wayne Li wrote:
>
>> Hi All,
>>
>>
> Hi. Thanks you for communicating the versions and the configuration below.
> That helps a lot in helping you.
>
> Can you also provide the version of the mod_jk module ? It should be in
> the first line of the Apache httpd error log (when it starts up).
>
> I have a servlet/jsp application running on tomcat 7.0.47. There are no
>> static html files.
>> Now I am try to use apache 2.4.7 (Ubuntu)
>> as the front and forwad eveything to tomcat. I installed mod_jk using
>> Ubuntu's software
>> center.. Things are working: I type "localhost" on my brower bar, it shows
>> my application.
>>
>> Then, I also trying to use ssl and generated self-signed certificate. It
>> works, because
>> the browser warns me about unknown certificate. If I type "
>> https://www.mytest.com/index.jsp;
>> on the browser's bar, it shows the page. But not correctly: the page
>> contains:
>>  
>>  
>> These extra files are not be called.
>>
>
> Sorry to ask, but *are* these files present, in the same directory as your
> index.jsp page ?
>
>
> What is wrong on my side? Any information would be appreciated. Thank you
>> in advance.
>>
>
> There is some configuration information missing below : in
> /etc/apache2/mods-available, there should be a couple of files : jk.load
> and jk.conf.
> What is the content of these files ?
>
>
>> the /etc/apache2/conf/default-ssl.conf:
>>
>>  
>>SSLEngine on
>>SSLCertificateFile /etc/apache2/ssl/server.crt
>>SSLCertificateFile /etc/apache2/ssl/server.crt
>>
>
> above, duplicate lines ?
>
>
>JkMount /* ajp13_worker
>>  
>>
>>
>> the /etc/apache2/conf/000-default.conf:
>> 
>>ServerName localhost
>>DocumentRoot /ROOT
>>JkMountCopy On
>>
>>  JkMount jk-status
>>  Order deny,allow
>>  Allow from 127.0.0.1,localhost
>>
>>
>>  JkMount jk-manager
>>  Order deny,allow
>>  Allow from 127.0.0.1,localhost
>> 
>> 
>>
>> the /etc/apache2/workers/worker.properties:
>>workers.tomcat_home=/tomcat
>>workers.java_home=/jdk8
>>ps=/
>>worker.list=ajp13_worker
>>worker.ajp13_worker.port=8009
>>worker.ajp13_worker.host=localhost
>>worker.ajp13_worker.type=ajp13
>>worker.ajp13_worker.lbfactor=1
>>worker.loadbalancer.type=lb
>>worker.loadbalancer.balance_workers=ajp13_worker
>>worker.list=jk-status
>>worker.jk-status.type=status
>>worker.jk-status.read_only=true
>>worker.list=jk-manager
>>worker.jk-manager.type=status
>>
>>
> That workers.properties looks old, and contains some deprecated lines :
> >workers.tomcat_home=/tomcat
> >workers.java_home=/jdk8
>
> Also, you do not have a load-balancing setup, so I suggest to simplify the
> above and just have the following in worker.properties :
>
> >worker.list=ajp13_worker
> >worker.ajp13_worker.port=8009
> >worker.ajp13_worker.host=localhost
> >worker.ajp13_worker.type=ajp13
>
> You can find this here :
> http://tomcat.apache.org/connectors-doc/common_howto/quick.html
> -> Minimum workers.properties
>
> If you need the rest, you can re-add it later.
>
> Another recommendation : use the browser feature (or plugin or add-on)
> that allows you to see the exact dialog between the browser and the server
> (HTTP requests, HTTP responses, status codes, HTTP headers etc.). That will
> immensely simplify the debugging work.
> For example, in Mozilla Firefox I use "LiveHTTPHeaders",
> and with IE, I use "Fiddler2".
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-11 Thread tomcat

On 11.07.2016 15:57, Wayne Li wrote:

Hi All,



Hi. Thanks you for communicating the versions and the configuration below.
That helps a lot in helping you.

Can you also provide the version of the mod_jk module ? It should be in the first line of 
the Apache httpd error log (when it starts up).



I have a servlet/jsp application running on tomcat 7.0.47. There are no
static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forwad eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working: I type "localhost" on my brower bar, it shows
my application.

Then, I also trying to use ssl and generated self-signed certificate. It
works, because
the browser warns me about unknown certificate. If I type "
https://www.mytest.com/index.jsp;
on the browser's bar, it shows the page. But not correctly: the page
contains:
 
 
These extra files are not be called.


Sorry to ask, but *are* these files present, in the same directory as your 
index.jsp page ?



What is wrong on my side? Any information would be appreciated. Thank you
in advance.


There is some configuration information missing below : in /etc/apache2/mods-available, 
there should be a couple of files : jk.load and jk.conf.

What is the content of these files ?



the /etc/apache2/conf/default-ssl.conf:
   
 
   SSLEngine on
   SSLCertificateFile /etc/apache2/ssl/server.crt
   SSLCertificateFile /etc/apache2/ssl/server.crt


above, duplicate lines ?


   JkMount /* ajp13_worker
 
   

the /etc/apache2/conf/000-default.conf:

   ServerName localhost
   DocumentRoot /ROOT
   JkMountCopy On
   
 JkMount jk-status
 Order deny,allow
 Allow from 127.0.0.1,localhost
   
   
 JkMount jk-manager
 Order deny,allow
 Allow from 127.0.0.1,localhost



the /etc/apache2/workers/worker.properties:
   workers.tomcat_home=/tomcat
   workers.java_home=/jdk8
   ps=/
   worker.list=ajp13_worker
   worker.ajp13_worker.port=8009
   worker.ajp13_worker.host=localhost
   worker.ajp13_worker.type=ajp13
   worker.ajp13_worker.lbfactor=1
   worker.loadbalancer.type=lb
   worker.loadbalancer.balance_workers=ajp13_worker
   worker.list=jk-status
   worker.jk-status.type=status
   worker.jk-status.read_only=true
   worker.list=jk-manager
   worker.jk-manager.type=status



That workers.properties looks old, and contains some deprecated lines :
>workers.tomcat_home=/tomcat
>workers.java_home=/jdk8

Also, you do not have a load-balancing setup, so I suggest to simplify the above and just 
have the following in worker.properties :


>worker.list=ajp13_worker
>worker.ajp13_worker.port=8009
>worker.ajp13_worker.host=localhost
>worker.ajp13_worker.type=ajp13

You can find this here : 
http://tomcat.apache.org/connectors-doc/common_howto/quick.html
-> Minimum workers.properties

If you need the rest, you can re-add it later.

Another recommendation : use the browser feature (or plugin or add-on) that allows you to 
see the exact dialog between the browser and the server (HTTP requests, HTTP responses, 
status codes, HTTP headers etc.). That will immensely simplify the debugging work.

For example, in Mozilla Firefox I use "LiveHTTPHeaders",
and with IE, I use "Fiddler2".




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



Re: Need help setting up SSL on Tomcat 8

2016-07-11 Thread Sean Son
Here is the certificate path:

- Go Daddy Root Certificate Authority - G2
   - Go Daddy Secure Certificate Authority - G2
  - *.example.com


Thanks

On Fri, Jul 8, 2016 at 6:23 PM, Ognjen Blagojevic <
ognjen.d.blagoje...@gmail.com> wrote:

> On 7.7.2016 23:17, Daniel Savard wrote:
>
>> Certificate Error
> There are issues with the site's certificate chain
> (net::ERR_CERT_COMMON_NAME_INVALID).
>
> Looks like adding the keyAlias to the connector did not fix anything
> unfortunately.
>
>

>>> Did you examined the received certificate in the browser. Usually this
>> help
>> to identify why it failed. In this case, the chain of certification seems
>> to be the problem.
>>
>
> +1
>
> What is your certification path / certificate hierarchy?
>
> In Firefox: click on padlock icon, click on arrow, More information, View
> Certificate, Details, Certificate Hierarchy
>
> In Chrome: click on padlock icon, Details, View Certificate, Certification
> path.
>
>
> -Ognjen
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-11 Thread Wayne Li
Hi All,

I have a servlet/jsp application running on tomcat 7.0.47. There are no
static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forwad eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working: I type "localhost" on my brower bar, it shows
my application.

Then, I also trying to use ssl and generated self-signed certificate. It
works, because
the browser warns me about unknown certificate. If I type "
https://www.mytest.com/index.jsp;
on the browser's bar, it shows the page. But not correctly: the page
contains:


These extra files are not be called.
What is wrong on my side? Any information would be appreciated. Thank you
in advance.

the /etc/apache2/conf/default-ssl.conf:
  

  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/server.crt
  SSLCertificateFile /etc/apache2/ssl/server.crt
  JkMount /* ajp13_worker

  

the /etc/apache2/conf/000-default.conf:

  ServerName localhost
  DocumentRoot /ROOT
  JkMountCopy On
  
JkMount jk-status
Order deny,allow
Allow from 127.0.0.1,localhost
  
  
JkMount jk-manager
Order deny,allow
Allow from 127.0.0.1,localhost
   


the /etc/apache2/workers/worker.properties:
  workers.tomcat_home=/tomcat
  workers.java_home=/jdk8
  ps=/
  worker.list=ajp13_worker
  worker.ajp13_worker.port=8009
  worker.ajp13_worker.host=localhost
  worker.ajp13_worker.type=ajp13
  worker.ajp13_worker.lbfactor=1
  worker.loadbalancer.type=lb
  worker.loadbalancer.balance_workers=ajp13_worker
  worker.list=jk-status
  worker.jk-status.type=status
  worker.jk-status.read_only=true
  worker.list=jk-manager
  worker.jk-manager.type=status


Tomcat 8.0 : Custom server.xml path

2016-07-11 Thread Amit Pande
Hello all,


We have a custom cluster deployment scenario which requires to put config
files on a shared disk.

With reference to above requirement, we need to put server.xml (and
possibly other files from TOMCAT_DIR\conf) on the shared disk.

Is there any way to do this ? Possible to do in catalina.properties like:


Conf.dir = 


Appreciate your help here.

Thanks,
Amit


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