[SECURITY] CVE-2014-0227 Apache Tomcat Request Smuggling

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2014-0227 Request Smuggling

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 8.0.0-RC1 to 8.0.8
- - Apache Tomcat 7.0.0 to 7.0.54
- - Apache Tomcat 6.0.0 to 6.0.41

Description:
It was possible to craft a malformed chunk as part of a chucked request
that caused Tomcat to read part of the request body as a new request.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 8.0.9 or later
- - Upgrade to Apache Tomcat 7.0.55 or later
- - Upgrade to Apache Tomcat 6.0.43 or later
  (6.0.42 contains the fix but was not released)

Credit:
This issue was identified by the Tomcat security team.

References:
[1] http://tomcat.apache.org/security-8.html
[2] http://tomcat.apache.org/security-7.html
[3] http://tomcat.apache.org/security-6.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJU2HoOAAoJEBDAHFovYFnn/3wP/A3qNw/M6hrPYGtZJGtHmb3b
B7VMHvhW18nTVUIuS6pg/FIcLg//dRpzzosHGAygGZJRTqW6am3TF9IEGrtaqXED
3cLbIUcIlay8grokG5Ci4fduZ3pouVA8/xbWTW6ND0KORAAsCeeIVVs3+/IdyBrM
hRMST00A/ryXEBCzUdVATjd7bpdOAnRW/lSUI5/Ap+zQN1SR6rBdF224UaWRiZrr
4t55ZnStDQ10OT5a8R/uSZAftnRD3wRzOCquYHA7PbzpjDDmwbz00BQWErmlmgs/
ElN9Dmdn+/dFaaU9AGOLEhsse3KajfjgdWVXRoB2BJW3/GFgPT9vcHswINEgAZtp
HoNFavmlZr0bs+1YdSEx8qtitB6Wr4QiwWYzfwLMhZ3qx6g0NSTMY6g+JH7BVIOL
3xGf1B42LidgMqqpcyddLW3HFICRI6wX1IgK+rF8Obaga6UOCHgmCKTL4YBxe5XK
+YqEgH3HE1jwTL04FGsVMSAUIx4Z5wkm0rXsf3emHsyDytFQOyrJqI8AdGVMyOwO
ZEjqwFDCjW36I2YsoE4HffO/ZnTxJrZzOZOXXt7N7zfFfxXsJsSuBBM3il0VIPyB
AdmOl1RoeGx5Gj2WGIgXjPLCcOHaNTobClasFMvuzgPmxIHPViT1fhM/M41cre8M
v3iXCWFfOe15UtdBy57w
=BK1a
-END PGP SIGNATURE-

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

finding out the exact tomcat version under Ubuntu 14.04 (trusty)

[Christoph P.U. Kukulies]

As the subject says: How can I find out the exact tomcat version under 
Ubuntu 14.04 (trusty)?


Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de

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

WARNING: Problem with directory [/usr/share/tomcat7/common], exists: [false],

[Christoph P.U. Kukulies]

What are these warnings an stacktraces about?

Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common/classes], 
exists: [false], isDirectory: [false], canRead: [false]
Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat7/common], exists: 
[false], isDirectory: [false], canRead: [false]
Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat7/server/classes], 
exists: [false], isDirectory: [false], canRead: [false]
Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat7/server], exists: 
[false], isDirectory: [false], canRead: [false]
Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat7/shared/classes], 
exists: [false], isDirectory: [false], canRead: [false]
Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory 
validateFile
WARNING: Problem with directory [/usr/share/tomcat7/shared], exists: 
[false], isDirectory: [false], canRead: [false]

Feb 09, 2015 11:42:10 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8443"]
Feb 09, 2015 11:42:10 AM 
org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore
SEVERE: Failed to load keystore type JKS with path 
/usr/share/tomcat7/.keystore due to /usr/share/tomcat7/.keystore (No 
such file or directory)
java.io.FileNotFoundException: /usr/share/tomcat7/.keystore (No such 
file or directory)

at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:146)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:385)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:291)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:549)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:489)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:434)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:181)
at 
org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:397)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:640)
at 
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434)
at 
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:978)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:813)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)

at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:663)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:454)

Feb 09, 2015 11:42:10 AM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler 
["http-bio-8443"]
java.io.FileNotFoundException: /usr/share/tomcat7/.keystore (No such 
file or directory)

at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:146)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:385)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:291)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:549)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:489)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:434)



Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.or

Re: finding out the exact tomcat version under Ubuntu 14.04 (trusty)

[Mark Thomas]

On 09/02/2015 10:48, Christoph P.U. Kukulies wrote:
> As the subject says: How can I find out the exact tomcat version under
> Ubuntu 14.04 (trusty)?

The short version is that the version of Tomcat provided by Ubuntu may
not be an exact match for a version released by the ASF. The problem is
that Linux distributions often update to a Tomcat version and then, when
a new version with a security fix is released, backport just the fix
rather than updating to the new release.

What you really need to know is the base version and what patched have
been applied.

And that is before you get into the habit Linux distros have of
distributing a Tomcat install all over the file system. (Yes they have a
good reason for doing this but this has been known to cause issues and
it makes it a whole lot more difficult for us to support because we have
no idea what files have been put where.)

I'd recommend starting here:
http://packages.ubuntu.com/trusty/java/tomcat7

It looks like the latest version is based on 7.0.52 with patches for the
known issues in 7.0.53.

It looks like they opted not to patch for the known issue in 7.0.54.
Hmm. Not sure I entirely agree with that call. If you are running shared
Tomcat hosting on Ubuntu Trusty you'd have a problem.

They haven't included in the fix for 7.0.55 either but since it was only
announced a few hours ago it isn't reasonable to expect them to react
that fast.

Mark

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

Re: WARNING: Problem with directory [/usr/share/tomcat7/common], exists: [false],

[Mark Thomas]

On 09/02/2015 11:00, Christoph P.U. Kukulies wrote:
> What are these warnings an stacktraces about?

You've configured Tomcat to load classes from directories that don't
exist (or to more exact are not visible to the user Tomcat is running as).


> Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory
> validateFile
> WARNING: Problem with directory [/usr/share/tomcat8/common/classes],
> exists: [false], isDirectory: [false], canRead: [false]
> Feb 09, 2015 11:42:09 AM org.apache.catalina.startup.ClassLoaderFactory
> validateFile
> WARNING: Problem with directory [/usr/share/tomcat7/common], exists:
> [false], isDirectory: [false], canRead: [false]



Hmm. Tomcat 8 and Tomcat 7 in the same config. Something looks to be broken.

> Feb 09, 2015 11:42:10 AM
> org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore
> SEVERE: Failed to load keystore type JKS with path
> /usr/share/tomcat7/.keystore due to /usr/share/tomcat7/.keystore (No
> such file or directory)

Tomcat has been configured to load a keystore from a location it can;t
access.

Mark


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

[ANN] Apache Tomcat 7.0.59 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.59.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.57. The notable changes since 7.0.57 include:


- Session ID Generator is now extensible.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.32 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team

Re: Sporadic HTTP 403 returned by Tomcat when this should not happen ever. How to find out why this happens?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/6/15 11:58 AM, Mark Eggers wrote:
> CORS basically doesn't with Internet Explorer < 10.
> 
> IE < 8, and CORS does not work at all. IE 8 - Microsoft has a
> 'special mechanism' for CORS IE 9 - Microsoft breaks the 'special
> mechanism' IE 10 - Microsoft tells people to use CORS
> 
> http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx
>
>  . . . been there, fought that

Hmm. Sounds like it's worth adding that to the CORSFilter
documentation, at least in summary (similar to above, including the link).

Could you make a docs patch?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2MHkAAoJEBzwKT+lPKRYcV4P/1b1N+BztmSHThMp7UQ993P/
vA4xbeU7ueskAciAiFAcfHtjOKlA1614YJPhOxNSLYVKOBlOyMhfJPjSFbhFazbH
ZgDY1ZyVVtqje5/5SmCL8lolMSNAGhktzgDOKB+yINQzzTnqtmOUBOzz3ZpDV4yi
TNnj8e79Cy/2Ubq24vp6FFxemEnoYbcy87zEW4U0uBqchlUCRqGVncQ1WKA3glBo
q4QozYiQorxY40nbNC6zEy1LxjlAjdWpimY/Sqrmgb9wb9lkmn5P9ZUEowM+y7SL
ULENuHAXZk+2P5RbTB02VNgwZ3Hz1Rb4FEbIUfDO1sF49fVmQxyFLo1AgzFNLXyJ
IK+Jm274K8wmdRC66duXbaKW5yqsF9TWehxKTNidvblFLbTENKbCZf+UIGBsb7qf
LhNcIutD5ZhoXtfUVCT0HtvC2/Fa8THI/qIUJaJ6rp2Zi2m1fZt2uWroFmpoFeik
RU7f+99QtBKzxxQ4TlhORBtmig1fuKhlAmlcXbwIi4eeHezsgkq7y6O9UtKNHo8c
WWCwdcJGq8e+RVbwO33+jFbuyo5hPotL3DiQmG0aaJvMYfeJCo2Ma6nUiK8PEjyR
FuyBESUdBdeCrc5f3fPZGzYsYraHyC+zuOqAwEwTr6JBEUO0MhBd7vTWNtNF9x95
gs2LQSgBikYX/MpNDOeU
=qhUC
-END PGP SIGNATURE-

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

Re: File getting created in bin folder instead of project folder

[André Warnier]

Hyder Hashmi wrote:

Hi All,

When I execute the following code in my project folder, it creates the file
in my current folder(project folder).

import java.io.File;
public class CreateFile{
  File f = null;
  try{
 f = new File("test.txt");
 bool = f.createNewFile();
 System.out.println("File created: "+bool);
 }catch(Exception e){
 e.printStackTrace();
  }
}

I am now calling this class in my servlet.
The servlet is executing perfectly on the tomcat, however, the file is
getting created in the tomcat's bin folder instead of my project folder
placed in the webapps.

If I specify the path, then it creates the file on that location , however,
that will be hardcoding and will not work on the other computer.



Hyder,

apart from all the advice which you have already received, here is maybe a more general 
explanation, so that you would understand what you have been told so far.


When you run Tomcat, the process which is really running is a Java Virtual Machine (a 
JVM), which compiles and runs the code of Tomcat.  Your web application runs under Tomat, 
which means basically that it gets compiled and run by the JVM, as a part of Tomcat.
Tomcat is a Java Servlet Engine, which is an application designed to run Java servlets 
(like your application), according to the specifications given in the official Java 
Servlet Specification.  Tomcat is not the only Java Servlet Engine, but they all follow 
these same specifications.
If you want your web application to be portable to any Java servlet Engine, your 
application must also conform to the rules of the Java Servlet Specification.


One of these "rules" (or, in this case, the absence of one) is about the fact that you 
cannot rely on your web application being able to write in whatever directory (if any) is 
its "current" directory (even supposing that this exists at all).  This "current 
directory" is whatever directory the JVM happens to be running in, which you have no way 
to know in advance.
(Some day, your application may even be running inside a JVM and a Tomcat that are 
entirely in some non-writeable kind of memory.)


So, what everyone has been trying to tell you, is that the only way to do what you 
apparently want to do (have that application write something somewhere), and to do this in 
a portable way, is to choose a place *outside* of the Tomcat directories, some place that 
is guaranteed to be writeable (by the JVM which runs Tomcat and your webapp) because you 
created it that way (and you include this in your application's installation 
instructions).  And to make this portable, your application has to be able to find out 
that location (on each system where it may be used), via some *configurable* parameter 
that it can read.

And there are some suggestions in previous responses, to tell you how to do 
that.

And finally, there is another reason for not writing inside your web application's 
directory, even if this was possible : security.  If you allow Tomcat to write to your 
application directory, then possibly someone can take advantage of this via some 
misconfiguration, and overwrite your code with malicious code that would do something else 
which you do not want to happen at all.  And you would be blamed.








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

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick,

(The formatting was awful on the message and made it difficult to
read. I've adjusted it to make it readable and reply-able).

On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
> I have a SHA2 certificate for a RHEL 6 server using tomcat 7.0.57.

That's an x509 certificate for SSL/TLS, using a SHA2-based signature
algorithm, right?

> Port 8443 is listening, selinux is disabled, and have tried it
> with 8443 enabled in firewall and with firewall off.
> 
> After receiving the .crt file from GoDaddy: ran the 4 keytool
> -import commands:
> 
> For the alias=root, I used gdroot-g2.crt(from repository) For the
> alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
> alias=cross, I used gdroot-g2_cross.crt(from repository) For the
> alias= tomcat, I used the .crt(from GoDaddy)
> 
> I see all the entries when I did the keytool -list

Good. Everything above looks good, except that you need to make sure
that the certificates you imported were all the correct ones... thee
days, CAs tend to have a variety of intermediate certificates for
various purposes: one for code-signing, one for European certificates
and another for American ones, an old one with SHA1-based signature,
new ones with SHA2-based signatures, etc.

Verifying the accuracy of the certificate chain should be a priority.

> I made this change in server.xml:
> 
>  scheme="https" secure="true" clientAuth="false"
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="path to
> .keystore file" keystorePass="keystore password" />
> 
> I then shutdown tomcat; startup tomcat.
> 
> When I go to the URL in the browser with the port 8443, I get 
> this:Firefox: Cannot communicate securely with peer: no common 
> encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
> 
> Chrome: A secure connection cannot be established because this
> site uses an unsupported protocol.Error code: 
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What version of Chrome are you using?

Do you have access to an OpenSSL library? Can you run "openssl -debug
- -showcerts s_client -connect https://host:8443/"; and post the
(possibly sanitized) results?

You could also grab and compile the source of this tool from the
tomcat-dev archives and run it against your server:
http://markmail.org/thread/tz4z44nfjl7sy2lj

This will tell you what is and is not supported.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2MSbAAoJEBzwKT+lPKRYOa4P+gNuh8c8eHozKFAHvdJd9UYc
4C1UYHGCJ6R6JYDysTG/iKWSZH94GbzNldtP/DuiNelDFy/vPDEagXrrFdMNyGWp
PksnjVqneKxSs9Sm1ccYD03A3WTGryz5r1MKRezfMlYJWRxAPcsaNotSHzI8pkpT
HG2nqVGGGbgZI88fJOZD58eJLB6fRTVC/Z2CfXmJSUns/A35AdfBZjc+FrrAGVqi
7ssMfLK4gdpUsnZWqjTpoICRhJiAzayptJOpIVK3rkmCQzccw4DUU87QZqVK57md
/TsNHsnQsnLzKwM1lxrs0H3AVHYxPZyS5mTW7PcM8zWI4Iudlao6U+5mUZQCeEoK
6/+AvXiE+SEqDj3sS6p2IeYl19IcITCp57UD8IR3P8vFKmaF6cjDguJEnJi9BAh+
LkLZeMsuqRQpUusuXlQaCOxZjFUvQk2WtAA06e+vrtNP6+GtSyD8JyVspD5QlarS
XMqeE5aPoaKbQKTpqBKDyasC2ae8KP0RkxfLYq+NSWxHw727Rl65nr/PVLmjQ00E
n/+fzq9U8vj+8k/IRPpErwg0Ns9wkztkNlH9hJUSXALdfXPVKo6joqI7eRfqXa+K
uJ57fgRi3fMk7Z0h4z/hvxENkebn9ySeS5bH9sfceVc6FBS1mcTuHxq4G8XYd/WO
2CA9DwlS0hMtRDLuPvAl
=sJsq
-END PGP SIGNATURE-

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

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[Sean Dawson]

We've had customers who have had issues with Java and GoDaddy certs.

http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/


On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Nick,
>
> (The formatting was awful on the message and made it difficult to
> read. I've adjusted it to make it readable and reply-able).
>
> On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
> > I have a SHA2 certificate for a RHEL 6 server using tomcat 7.0.57.
>
> That's an x509 certificate for SSL/TLS, using a SHA2-based signature
> algorithm, right?
>
> > Port 8443 is listening, selinux is disabled, and have tried it
> > with 8443 enabled in firewall and with firewall off.
> >
> > After receiving the .crt file from GoDaddy: ran the 4 keytool
> > -import commands:
> >
> > For the alias=root, I used gdroot-g2.crt(from repository) For the
> > alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
> > alias=cross, I used gdroot-g2_cross.crt(from repository) For the
> > alias= tomcat, I used the .crt(from GoDaddy)
> >
> > I see all the entries when I did the keytool -list
>
> Good. Everything above looks good, except that you need to make sure
> that the certificates you imported were all the correct ones... thee
> days, CAs tend to have a variety of intermediate certificates for
> various purposes: one for code-signing, one for European certificates
> and another for American ones, an old one with SHA1-based signature,
> new ones with SHA2-based signatures, etc.
>
> Verifying the accuracy of the certificate chain should be a priority.
>
> > I made this change in server.xml:
> >
> >  > scheme="https" secure="true" clientAuth="false"
> > sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="path to
> > .keystore file" keystorePass="keystore password" />
> >
> > I then shutdown tomcat; startup tomcat.
> >
> > When I go to the URL in the browser with the port 8443, I get
> > this:Firefox: Cannot communicate securely with peer: no common
> > encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
> >
> > Chrome: A secure connection cannot be established because this
> > site uses an unsupported protocol.Error code:
> > ERR_SSL_VERSION_OR_CIPHER_MISMATCH
>
> What version of Chrome are you using?
>
> Do you have access to an OpenSSL library? Can you run "openssl -debug
> - -showcerts s_client -connect https://host:8443/"; and post the
> (possibly sanitized) results?
>
> You could also grab and compile the source of this tool from the
> tomcat-dev archives and run it against your server:
> http://markmail.org/thread/tz4z44nfjl7sy2lj
>
> This will tell you what is and is not supported.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJU2MSbAAoJEBzwKT+lPKRYOa4P+gNuh8c8eHozKFAHvdJd9UYc
> 4C1UYHGCJ6R6JYDysTG/iKWSZH94GbzNldtP/DuiNelDFy/vPDEagXrrFdMNyGWp
> PksnjVqneKxSs9Sm1ccYD03A3WTGryz5r1MKRezfMlYJWRxAPcsaNotSHzI8pkpT
> HG2nqVGGGbgZI88fJOZD58eJLB6fRTVC/Z2CfXmJSUns/A35AdfBZjc+FrrAGVqi
> 7ssMfLK4gdpUsnZWqjTpoICRhJiAzayptJOpIVK3rkmCQzccw4DUU87QZqVK57md
> /TsNHsnQsnLzKwM1lxrs0H3AVHYxPZyS5mTW7PcM8zWI4Iudlao6U+5mUZQCeEoK
> 6/+AvXiE+SEqDj3sS6p2IeYl19IcITCp57UD8IR3P8vFKmaF6cjDguJEnJi9BAh+
> LkLZeMsuqRQpUusuXlQaCOxZjFUvQk2WtAA06e+vrtNP6+GtSyD8JyVspD5QlarS
> XMqeE5aPoaKbQKTpqBKDyasC2ae8KP0RkxfLYq+NSWxHw727Rl65nr/PVLmjQ00E
> n/+fzq9U8vj+8k/IRPpErwg0Ns9wkztkNlH9hJUSXALdfXPVKo6joqI7eRfqXa+K
> uJ57fgRi3fMk7Z0h4z/hvxENkebn9ySeS5bH9sfceVc6FBS1mcTuHxq4G8XYd/WO
> 2CA9DwlS0hMtRDLuPvAl
> =sJsq
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat CORS Filter: Why is the default list of headers in "Access-Control-Allow-Headers" so arbitrarily limited?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 2/7/15 12:21 PM, Brian wrote:
> Tomcat brings a special filter that implements the CORS
> specification. In this filter, the default list of allowed headers
> is the following:
> 
> Origin Accept X-Requested-With Content-Type 
> Access-Control-Request-Method Access-Control-Request-Headers
> 
> 
> 
> I know that I can replace that list by using the filter parameter 
> "cors.allowed.headers" and specify my own list of headers. I know
> that. But I have the following questions:
> 
> - When this filter was created, why was the list filled with this 
> -abritrarily- short list of headers? Why these headers and not
> others? Why, for example, isn't the "cache-control" header in the
> list? How was this list chosen?

The W3C CORS "standard" recommendation
(http://www.w3.org/TR/cors/#access-control-allow-headers-response-header)
does not specify which headers should be included by default in this
list. So, it's probably up to the implementer to determine that list.

The author probably wanted to cover the smallest number of low-risk
headers for a default configuration. As you've said, the default can
be overridden. This is a fairly new Filter in Tomcat, so there may
have been some oversights.

The spec mentions "simple headers" of which "Cache-Control" is one. I
haven't read the spec well enough -- nor the code at all -- to know if
those "simple headers" are included by default but not mentioned.

The "cors.exposed.headers" specifically mentions them but
"cors.allowed.headers" does not. I suspect this is accurate, and that
no simple headers are included by default. If you want to add
"Cache-Control" then you should probably add it yourself.

> - If I want to define a more complete list, which headers should I
> include? There are some many headers to think about!

Now you see why the original author might have had a hard time
determining the default list.

> - Can I use a "*" instead of specifying a list? Is that something
> that the CORS specs allows?

This kind of defeats the purpose of the tool in the first place,
doesn't it?

> - I know that the CORS specs defined this kind of list, but. Why is
> that necessary? Why can't we just accept any header in the
> pre-flight OPTIONS step, instead of returning a 403 (Forbiden) if
> at least one of the headers requested by the client is not in the
> list of allowed headers?

You certainly /can/ do that, but then you remove a layer of security
that the tool is supposed to provide.

> - Why isn't there an option in the filter to do something like
> this:
> 
> response.setHeader("Access-Control-Allow-Headers", 
> request.getHeader("Access-Control-Request-Headers")?

This would accept anything the client sent (which, of course, is what
you're asking about). "Custom headers" are a potential attack vector
and part of the reason that header white-listing is a part of the CORS
spec.

> I'm puzzled. One of the users of my API sent the "cache-control"
> header in the in the "Access-Control-Request-Headers" list during
> the pre-flight step, and received an HTTP 403 error status. I can
> add this header to the list (using the "cors.allowed.headers"
> filter parameter). But what about next time some client sends
> another header that is not in the list?

It sounds like you need to listen to to the needs of your customers
and adapt to them. You can either say "sure, we'll white-list that
header" or "sorry, you'll have to remove that header from your request
because we see it as a security issue".

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2MlHAAoJEBzwKT+lPKRYmxUQAK+cIucZ3jodP5wBvZugLz0m
iO2jDNDVz1KVJwDqsmtOaXQSFuGOsguUkyhbSW0RY4WMAbh4YellXDaXCC6zw02Q
vKzPJewvOyvmfN7Jztk2vmqfu0+ETFW6aVfWFz+azwUdzKv06Bs+rOlKgvbrtrtN
+hBqkFpZTMjDA77oc2i93fqv3GX8+Qy+XcaE0tMnULxcsLSoQzVJ6x03XyCvEpMX
v8SLWo12mUYio7VNBY56CeqxG+hCE9vY1hBVjzBM9kEzXe/YM/iOJAiocoScKcUn
8I1LA6kyCXYZM3ubYfaUV/jS0ebGXkeOyePuX1js1YC9vdgapzckwXNg1flUYs7i
9pbetj0n9E590eDaz3j6VaTchWf+RYL92CejU51g9/lvGN4whhAdFmehlV+TNJy/
gW95q2uY7SiU2ORepMKWI9zSQwFGDl+ve80jhupB4fg/xjk/cioe/VJQuazReyOj
JugpKH0Z3XjPXV5V2DneucvEhYyVtUqMqtTh7FPrZQL4xgGLslSDZSJHb2EDnyHt
7QqGU+2jhW5X0oxY6iFVBYgv2OX++ulAUcr14KH6vXfHLl4e8uCq0EuS9zXj29Ox
+bi3SBu3z62cLLV/gefzMjH3hmw+a0+f5/+xKc48aKADwat1W1051GjzWr+ErKOF
h1XH5OossOmsBCChwQcs
=Ok7B
-END PGP SIGNATURE-

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

Re: File getting created in bin folder instead of project folder

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hyder,

On 2/8/15 11:28 PM, Hyder Hashmi wrote:
> When I execute the following code in my project folder, it creates
> the file in my current folder(project folder).
> 
> import java.io.File; public class CreateFile{ File f = null; try{ f
> = new File("test.txt"); bool = f.createNewFile(); 
> System.out.println("File created: "+bool); }catch(Exception e){ 
> e.printStackTrace(); } }
> 
> I am now calling this class in my servlet. The servlet is executing
> perfectly on the tomcat, however, the file is getting created in
> the tomcat's bin folder instead of my project folder placed in the
> webapps.
> 
> If I specify the path, then it creates the file on that location ,
> however, that will be hardcoding and will not work on the other
> computer.

1. Use ServletContet.getRealPath("/path/inside/webapp").

2. Don't ever use ServletContext.getRealPath

The reason you shouldn't use getRealPath is because your web
application might not be deployed in an "unexploded" WAR file, and
therefore getRealPath will return null in that case, so you won't be
able to do anything with that path.

Instead, you need to use some other mechanism for writing files. What
do you plan to do with these files once they have been written? If you
intend to serve them back to clients using Tomcat's DefaultServlet,
that usually ends badly due to resource-caching, etc.

We have some servlets that write files to the filesystem for auditing
purposes. We have a configuration file that specifies where those
files should be written, and we load that file on startup. Perhaps
reading from a configuration file, or even from the servlet's
init-params, you can build a correct filesystem path and write your
files there.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2MzTAAoJEBzwKT+lPKRYV08QAIam6R7sR9c1YmPgkkuqEYM2
xoGUzcfnR6AFbRhTwu95W1k+yxHUqV+zaq6+z9ULBjXKVEO+0VS55EL9CTwDW1Xb
p64zP1zOdGq2pGJswIwj4voq94ZKQPKp6HK3hnuaA1RsskRY2Wvi7eiwskbw5KNi
AWI4iYHkJGQySUc5HnwwNLoZYqcpO7q5p91b/2Pk3r2g1hGBFZFM4KOHGfEjRgOH
VOUZnXmUEeJ7vIiOfbmJmvIZL/mBRdlzulVA7ID9JbiJs3id/WdzLun0Eh/DNnaX
ur1mhL+tZpuE+xy6WgkPAfMqkkzJ8R4jkn7c0YJZX+rmdHDJYj0WgjVYq53nBrMG
ogd3QHE32SesB6JCabveas57dQTLO6cykBMKZ7kWOkS1t+GNjemPWUKUIdpFb+pM
jqBOuXOOgRUPtqGO7b83B7QJILz1JvyCWHsfNzbnqi1WB/98AT2F0KrquNWOpJLF
IIGNBrpdeIh0Wlr8t5ZmOr806hnItWEHB1pqwCvBXok2jbllZrBaC+OqwloWah09
V3IfyHJKvux7BNA83SSK+wpHAYR2W7Esn1lYdxqmxYv4q4FqPbvATgnYVfR6wwVu
WD4nQVgNQl2CReDiT53SnQK6xKPMtCYYIa0jYybtB+0xNjKz3aemSW82JYvs+oj+
5qye5crH7bGxRs4cI09g
=LeVi
-END PGP SIGNATURE-

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

Re: 500 Error in Tomcat 7.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rajesh,

On 2/8/15 2:56 AM, Rajesh Biswas wrote:
> I am facing one critical issues with respect to SSL communication
> between java client and Tomcat Server (version 7.0.54).

Upgrade: see today's announcement of the vulnerability this release
contains. The latest release (also today) is 7.0.59.

> The problem is happening only the tomcat server installed in IOS
> Mavarick machine, and the problem is intermittent.(Windows machine
> the problem is not occurring)
> 
> I installed the generic version of tomcat in Mac OS 
> (apache-tomcat-7.0.54.zip distribution)
> 
> I did check in access log but I did not get any error message, but
> from client I am getting HTTP 500 code, the request is not reaching
> to application.
> 
> Would you please provide me pointers to debug as I did not get any
> server log to start debug the issue.
> 
> Please help me with your suggestion.

Tomcat runs just fine, including SSL, on Mac OS. I use it myself.

What do the server logs say when you start it up? What do the logs say
when you get the 500 error on the client? What client are you using?
What URL are you using?

you have not provided any information with which wen can make a diagnosis.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2M2MAAoJEBzwKT+lPKRYVx8QAIIEVf2ZfqgEXvs+JUueC8rF
HywFXdrN2sGuhEMvGUZjNMd3M/D1AQOohO6HoPJYC6ynIUEtmu5w2RrnynnaDXsJ
hVBR+SaU8MUDO6bNuIc2fx9TIzTjl+MSbt7AhNNL7tjFsjDjsh1y91E/h1Ussuem
6JEn0Wmv10AV2OVacpN9TSXZ8mvzcQ0Ib3TBK18j299Ceqh8viXMB9Bnk2uNf13r
OY+Ebivqaf0cUnfYi8wMR1bbN6rbxZYbg4jY28q3fBdj5Gv6CNB/e4OCCUtNYeUo
TYu5hGiqwHQljxRUiGiI6+XL9ozaotnjtqlHfzqGlH++u9KOVYm0Fb9AwsUKinnr
PUhTSqKrV6k6itX42U8Bms0vq84cMOXttIFJ/itqXIbnxeSgvnHfKWvyuyu/J0pV
ondrMhE7HLVCWdD9nGWmtT64iEJglqb2/rgBQVFbcquHg/IPik7v7TUx24fxChmr
ICJD0vS3WP7DekKCzHpEX+JwOdl8Y4KZAkYnpal9yOPJnYc6FVafRvPDcf9YLgRT
SaME0Ix2GzK4xSE5kw9JFG30wpVhLPBjUKlomw+JeLFSDZHkDMHATMRnTsKZXkZf
4PRn6q0DTFeJetm+3wpP9GC6gusTfBjDiLFg5/zYh/QDKhwCRkJQGRob/Hrudzmq
5UAats9YBzaSw45cXdAL
=qC6y
-END PGP SIGNATURE-

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

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

We are running 7.0.57. I have not tried to debug yet, but am willing to give it 
a try. I have gone to the apache site to download the source for that version 
but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, 
I'll take it down, otherwise, I'll update the executable and use the source for 
7.0.59.

I will try removing the CORS filter from the deployment and see if that changes 
the behavior. I'll update this thread when I know the results.

Thanks for your input.

Richard

> On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko  wrote:
> 
> 2015-02-06 23:30 GMT+03:00 RICHARD DOUST  >:
>> Hi,
>> 
>> I've got an application that ran well with Tomcat 6.0, but is causing me 
>> problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing 
>> requests to the isapi_redirect (1.2.40) filter which is configured to send 
>> some urls on to ajp13, then to port 8009 were Tomcat is listening), all 
>> running on Windows Server 2003.
>> 
>> I know the isapi filter is working because I've configured mappings to the 
>> Tomcat docs and manager web apps and can get to them without any problems 
>> (via IIS).
>> 
>> I have a servlet deployed to Tomcat that I'm POSTing to via an 
>> XMLHttpRequest in a browser. For the life of me, I cannot get it to respond 
>> to me with anything but a 403 and I can't figure out why. It is not a 
>> cross-domain request, so a CORS Filter (which is installed in support of a 
>> rewrite of the application which is underway) can't be having any effect. I 
>> have added an init-param to the servlet definition in the web.xml to make 
>> sure that it's not an issue having to do with the fact that it's a POST:
>> 
>> 
>>,
>>.
>>.
>>
>>readonly
>>false
>>
>> 
>> 
>> 
>> In the isapi_redirect.log I can see that the request is being passed to the 
>> ajp13 connector. The request is well formed. Everything is as it should be. 
>> The war file is configured as it was configured with Tomcat 6.0, in terms of 
>> its deployment descriptor with the above minor difference. Here is an 
>> excerpt from the isapi_redirect log with the request itself preceding what's 
>> shown here:
>> 
>> 00 00 00  - ManagerRqst>  (Tail end of request XML)
>> [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
>> pos=0 len=38 max=8192
>> [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 
>> 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 
>> 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 
>> 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>> ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
>> ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
>> [text/plain]
>> [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = 
>> [0]
>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
>> start_response::jk_isapi_plugin.c (1025): Starting response for URI 
>> '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
>> start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
>> [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
>> pos=0 len=2 max=8192
>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 
>> 00 00 00 00 00 00 00 00 00 00 00 00  - 
>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
>> ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
>> [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] 
>> HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK
>> [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
>> ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with 
>> socket 2300
>> [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c 
>> (3144): recycling connection pool for worker ajp13 and socket 2300
>> 
>> I have a breakpoint set in the servlet's doPost method. It gets hit if I use 
>> the rewrite which bypasses IIS and goes direct to port 8080 to hit Tomcat 
>> directly. It does not get hit when the request is sent 

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sean,

On 2/9/15 9:46 AM, Sean Dawson wrote:
> We've had customers who have had issues with Java and GoDaddy
> certs.
> 
> http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
>
>  
> http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/

Did
> 
you read the OP? He's already installed the GoDaddy cross-signed
certificate.

It's also not a Java client problem, since the client in this case is
Google Chrome.

- -chris

> On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Nick,
> 
> (The formatting was awful on the message and made it difficult to 
> read. I've adjusted it to make it readable and reply-able).
> 
> On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
 I have a SHA2 certificate for a RHEL 6 server using tomcat
 7.0.57.
> 
> That's an x509 certificate for SSL/TLS, using a SHA2-based
> signature algorithm, right?
> 
 Port 8443 is listening, selinux is disabled, and have tried
 it with 8443 enabled in firewall and with firewall off.
 
 After receiving the .crt file from GoDaddy: ran the 4
 keytool -import commands:
 
 For the alias=root, I used gdroot-g2.crt(from repository) For
 the alias=intermed, I used gd_ig2.crt(from GoDaddy) For the 
 alias=cross, I used gdroot-g2_cross.crt(from repository) For
 the alias= tomcat, I used the .crt(from
 GoDaddy)
 
 I see all the entries when I did the keytool -list
> 
> Good. Everything above looks good, except that you need to make
> sure that the certificates you imported were all the correct
> ones... thee days, CAs tend to have a variety of intermediate
> certificates for various purposes: one for code-signing, one for
> European certificates and another for American ones, an old one
> with SHA1-based signature, new ones with SHA2-based signatures,
> etc.
> 
> Verifying the accuracy of the certificate chain should be a
> priority.
> 
 I made this change in server.xml:
 
 >>> scheme="https" secure="true" clientAuth="false" 
 sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
 keystoreFile="path to .keystore file" keystorePass="keystore
 password" />
 
 I then shutdown tomcat; startup tomcat.
 
 When I go to the URL in the browser with the port 8443, I
 get this:Firefox: Cannot communicate securely with peer: no
 common encryption algorithm(s). (Error code:
 ssl_error_no_cypher_overlap)
 
 Chrome: A secure connection cannot be established because
 this site uses an unsupported protocol.Error code: 
 ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> 
> What version of Chrome are you using?
> 
> Do you have access to an OpenSSL library? Can you run "openssl
> -debug -showcerts s_client -connect https://host:8443/"; and post
> the (possibly sanitized) results?
> 
> You could also grab and compile the source of this tool from the 
> tomcat-dev archives and run it against your server: 
> http://markmail.org/thread/tz4z44nfjl7sy2lj
> 
> This will tell you what is and is not supported.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2M6yAAoJEBzwKT+lPKRYdo8QAKqyY87oXjHy4CkNc3fPjYQH
IQMRzFrnH/Dgk2g1eO9WXlJXg+4drjmDtsHpRBsJR17nZaDBz282lgVh4x8OUEhW
tK6eagXHHnwhA8HBCCey5f6EfCF7dMR6AbwLkbhTUN7aym4gYMmQM18q2Nt6jxz7
qmtHW5GZ4OscqA6MQ5SVT6FckKR83570WakPQsl64JJwCUbC0uwOL9nU654nckNy
hFiSznDugopfIICrmgHoX6HkAx7lChmCmfpexbUsDZkj/xpPriuvPMPu//sZ4zFc
euqin0/gDMy76Qr+H0ExHaMKH734vXWgjXTakHg5D/V0C8U4iQEJSBsDWCaXqvDX
kA+O2s/mYeiqqPVvA4nZ3JrNUQFgZPvOik8ubyCb2+/p7PLL9Hshikgl+sZ4cAW2
+NfertfDZ483IQKCKN1LKnWZNQ2ofF+jJ1vEoceqV/ybFi8fKipbJ37aU6c7EltL
h4zJFv86l/irYzVKweGuszX7xX9DwWUu7YdKx4wIVArncb+wrALx3NXF0bI8pMaC
C5sUoM2EBrOIZZkrpPDPdgr5O+XvWEaARd6eDnCDvZ1xjHcQxiHuVrnglzH3LE2L
rU6wfg4ZRaX5rMA++yetf4/qYOe+/+YW84zLK3VkL0jWdlldr6/QoActiUquI2OD
7fGjoyFAdo2GcZP1OloD
=T8m8
-END PGP SIGNATURE-

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

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[Sean Dawson]

On Mon, Feb 9, 2015 at 10:13 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sean,
>
> On 2/9/15 9:46 AM, Sean Dawson wrote:
> > We've had customers who have had issues with Java and GoDaddy
> > certs.
> >
> >
> http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
> >
> >
> >
> http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/
>
> Did
> >
> you read the OP? He's already installed the GoDaddy cross-signed
> certificate.
>
It's also not a Java client problem, since the client in this case is
> Google Chrome.
>

Oh ok sorry - I read it last week and forgot that it wasn't the same issue.
Just wanted to help out anyone else that might have run into the
GoDaddy/Java issue.


> - -chris
>
> > On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Nick,
> >
> > (The formatting was awful on the message and made it difficult to
> > read. I've adjusted it to make it readable and reply-able).
> >
> > On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
>  I have a SHA2 certificate for a RHEL 6 server using tomcat
>  7.0.57.
> >
> > That's an x509 certificate for SSL/TLS, using a SHA2-based
> > signature algorithm, right?
> >
>  Port 8443 is listening, selinux is disabled, and have tried
>  it with 8443 enabled in firewall and with firewall off.
> 
>  After receiving the .crt file from GoDaddy: ran the 4
>  keytool -import commands:
> 
>  For the alias=root, I used gdroot-g2.crt(from repository) For
>  the alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
>  alias=cross, I used gdroot-g2_cross.crt(from repository) For
>  the alias= tomcat, I used the .crt(from
>  GoDaddy)
> 
>  I see all the entries when I did the keytool -list
> >
> > Good. Everything above looks good, except that you need to make
> > sure that the certificates you imported were all the correct
> > ones... thee days, CAs tend to have a variety of intermediate
> > certificates for various purposes: one for code-signing, one for
> > European certificates and another for American ones, an old one
> > with SHA1-based signature, new ones with SHA2-based signatures,
> > etc.
> >
> > Verifying the accuracy of the certificate chain should be a
> > priority.
> >
>  I made this change in server.xml:
> 
>    scheme="https" secure="true" clientAuth="false"
>  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
>  keystoreFile="path to .keystore file" keystorePass="keystore
>  password" />
> 
>  I then shutdown tomcat; startup tomcat.
> 
>  When I go to the URL in the browser with the port 8443, I
>  get this:Firefox: Cannot communicate securely with peer: no
>  common encryption algorithm(s). (Error code:
>  ssl_error_no_cypher_overlap)
> 
>  Chrome: A secure connection cannot be established because
>  this site uses an unsupported protocol.Error code:
>  ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> >
> > What version of Chrome are you using?
> >
> > Do you have access to an OpenSSL library? Can you run "openssl
> > -debug -showcerts s_client -connect https://host:8443/"; and post
> > the (possibly sanitized) results?
> >
> > You could also grab and compile the source of this tool from the
> > tomcat-dev archives and run it against your server:
> > http://markmail.org/thread/tz4z44nfjl7sy2lj
> >
> > This will tell you what is and is not supported.
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJU2M6yAAoJEBzwKT+lPKRYdo8QAKqyY87oXjHy4CkNc3fPjYQH
> IQMRzFrnH/Dgk2g1eO9WXlJXg+4drjmDtsHpRBsJR17nZaDBz282lgVh4x8OUEhW
> tK6eagXHHnwhA8HBCCey5f6EfCF7dMR6AbwLkbhTUN7aym4gYMmQM18q2Nt6jxz7
> qmtHW5GZ4OscqA6MQ5SVT6FckKR83570WakPQsl64JJwCUbC0uwOL9nU654nckNy
> hFiSznDugopfIICrmgHoX6HkAx7lChmCmfpexbUsDZkj/xpPriuvPMPu//sZ4zFc
> euqin0/gDMy76Qr+H0ExHaMKH734vXWgjXTakHg5D/V0C8U4iQEJSBsDWCaXqvDX
> kA+O2s/mYeiqqPVvA4nZ3JrNUQFgZPvOik8ubyCb2+/p7PLL9Hshikgl+sZ4cAW2
> +NfertfDZ483IQKCKN1LKnWZNQ2ofF+jJ1vEoceqV/ybFi8fKipbJ37aU6c7EltL
> h4zJFv86l/irYzVKweGuszX7xX9DwWUu7YdKx4wIVArncb+wrALx3NXF0bI8pMaC
> C5sUoM2EBrOIZZkrpPDPdgr5O+XvWEaARd6eDnCDvZ1xjHcQxiHuVrnglzH3LE2L
> rU6wfg4ZRaX5rMA++yetf4/qYOe+/+YW84zLK3VkL0jWdlldr6/QoActiUquI2OD
> 7fGjoyFAdo2GcZP1OloD
> =T8m8
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

Ok. Found the archives for source. Now all I've got to do is figure out how to 
get Eclipse to look at the source when I'm running Tomcat remotely. I'll review 
that page you sent the link to.

Richard

> On Feb 9, 2015, at 10:14 AM, RICHARD DOUST  wrote:
> 
> We are running 7.0.57. I have not tried to debug yet, but am willing to give 
> it a try. I have gone to the apache site to download the source for that 
> version but can only find 7.0.59. If you can tell me how to get the source 
> for 7.0.57, I'll take it down, otherwise, I'll update the executable and use 
> the source for 7.0.59.
> 
> I will try removing the CORS filter from the deployment and see if that 
> changes the behavior. I'll update this thread when I know the results.
> 
> Thanks for your input.
> 
> Richard
> 
>> On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko  
>> wrote:
>> 
>> 2015-02-06 23:30 GMT+03:00 RICHARD DOUST > >:
>>> Hi,
>>> 
>>> I've got an application that ran well with Tomcat 6.0, but is causing me 
>>> problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing 
>>> requests to the isapi_redirect (1.2.40) filter which is configured to send 
>>> some urls on to ajp13, then to port 8009 were Tomcat is listening), all 
>>> running on Windows Server 2003.
>>> 
>>> I know the isapi filter is working because I've configured mappings to the 
>>> Tomcat docs and manager web apps and can get to them without any problems 
>>> (via IIS).
>>> 
>>> I have a servlet deployed to Tomcat that I'm POSTing to via an 
>>> XMLHttpRequest in a browser. For the life of me, I cannot get it to respond 
>>> to me with anything but a 403 and I can't figure out why. It is not a 
>>> cross-domain request, so a CORS Filter (which is installed in support of a 
>>> rewrite of the application which is underway) can't be having any effect. I 
>>> have added an init-param to the servlet definition in the web.xml to make 
>>> sure that it's not an issue having to do with the fact that it's a POST:
>>> 
>>> 
>>>   ,
>>>   .
>>>   .
>>>   
>>>   readonly
>>>   false
>>>   
>>> 
>>> 
>>> 
>>> In the isapi_redirect.log I can see that the request is being passed to the 
>>> ajp13 connector. The request is well formed. Everything is as it should be. 
>>> The war file is configured as it was configured with Tomcat 6.0, in terms 
>>> of its deployment descriptor with the above minor difference. Here is an 
>>> excerpt from the isapi_redirect log with the request itself preceding 
>>> what's shown here:
>>> 
>>> 00 00 00  - ManagerRqst>  (Tail end of request XML)
>>> [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
>>> pos=0 len=38 max=8192
>>> [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 
>>> 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
>>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 
>>> 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
>>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 
>>> 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
>>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
>>> ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
>>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
>>> ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
>>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
>>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
>>> [text/plain]
>>> [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
>>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = 
>>> [0]
>>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
>>> start_response::jk_isapi_plugin.c (1025): Starting response for URI 
>>> '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
>>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
>>> start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
>>> [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
>>> pos=0 len=2 max=8192
>>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
>>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 
>>> 00 00 00 00 00 00 00 00 00 00 00 00  - 
>>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
>>> ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
>>> [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] 
>>> HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK
>>> [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
>>> ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with 
>>> socket 2300
>>> [Fr

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[nicksemai...@juno.com]

On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
> I have a SHA2 certificate for a RHEL 6 server using tomcat 7.0.57.

That's an x509 certificate for SSL/TLS, using a SHA2-based signature
algorithm, right?

Yes, it is a SHA-2 algorithm from GoDaddy.  > Port 8443 is listening, selinux 
is disabled, and have tried it
> with 8443 enabled in firewall and with firewall off.
> 
> After receiving the .crt file from GoDaddy: ran the 4 keytool
> -import commands:
> 
> For the alias=root, I used gdroot-g2.crt(from repository) For the
> alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
> alias=cross, I used gdroot-g2_cross.crt(from repository) For the
> alias= tomcat, I used the .crt(from GoDaddy)
> 
> I see all the entries when I did the keytool -list

Good. Everything above looks good, except that you need to make sure
that the certificates you imported were all the correct ones... thee
days, CAs tend to have a variety of intermediate certificates for
various purposes: one for code-signing, one for European certificates
and another for American ones, an old one with SHA1-based signature,
new ones with SHA2-based signatures, etc.

Verifying the accuracy of the certificate chain should be a priority. Checked 
the filed from repository and checked with support that gdroot-g2.crt, 
gdig2.crt, gdroot-g2_cross.crt, and the alphanumeric.crt are accurate. 
> I made this change in server.xml:
> 
>  scheme="https" secure="true" clientAuth="false"
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="path to
> .keystore file" keystorePass="keystore password" />
> 
> I then shutdown tomcat; startup tomcat.
> 
> When I go to the URL in the browser with the port 8443, I get 
> this:Firefox: Cannot communicate securely with peer: no common 
> encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
> 
> Chrome: A secure connection cannot be established because this
> site uses an unsupported protocol.Error code: 
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What version of Chrome are you using?

Firefox 33.1
Chrome Version 40.0.2214.111 m I upgrade to Firefox 35 and got this when I put 
in the 8443 url:Firefox cannot guarantee the safety of your data on  
because it uses SSLv3, a broken security protocol.
Advanced info: ssl_error_no_cypher_overlap

Do you have access to an OpenSSL library? Can you run "openssl -debug
- -showcerts s_client -connect https://host:8443/"; and post the
(possibly sanitized) results?

When I ran this:#openssl s_client -connect :8443  (-debug and 
-showcerts was giving me invalid commands) I received:CONNECTED(0003)
error14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
failure:s23_clnt.c:744:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Thanks, Nick 

You could also grab and compile the source of this tool from the
tomcat-dev archives and run it against your server:
http://markmail.org/thread/tz4z44nfjl7sy2lj

This will tell you what is and is not supported.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU2MSbAAoJEBzwKT+lPKRYOa4P+gNuh8c8eHozKFAHvdJd9UYc
4C1UYHGCJ6R6JYDysTG/iKWSZH94GbzNldtP/DuiNelDFy/vPDEagXrrFdMNyGWp
PksnjVqneKxSs9Sm1ccYD03A3WTGryz5r1MKRezfMlYJWRxAPcsaNotSHzI8pkpT
HG2nqVGGGbgZI88fJOZD58eJLB6fRTVC/Z2CfXmJSUns/A35AdfBZjc+FrrAGVqi
7ssMfLK4gdpUsnZWqjTpoICRhJiAzayptJOpIVK3rkmCQzccw4DUU87QZqVK57md
/TsNHsnQsnLzKwM1lxrs0H3AVHYxPZyS5mTW7PcM8zWI4Iudlao6U+5mUZQCeEoK
6/+AvXiE+SEqDj3sS6p2IeYl19IcITCp57UD8IR3P8vFKmaF6cjDguJEnJi9BAh+
LkLZeMsuqRQpUusuXlQaCOxZjFUvQk2WtAA06e+vrtNP6+GtSyD8JyVspD5QlarS
XMqeE5aPoaKbQKTpqBKDyasC2ae8KP0RkxfLYq+NSWxHw727Rl65nr/PVLmjQ00E
n/+fzq9U8vj+8k/IRPpErwg0Ns9wkztkNlH9hJUSXALdfXPVKo6joqI7eRfqXa+K
uJ57fgRi3fMk7Z0h4z/hvxENkebn9ySeS5bH9sfceVc6FBS1mcTuHxq4G8XYd/WO
2CA9DwlS0hMtRDLuPvAl
=sJsq
-END PGP SIGNATURE-

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

The #1 Worst Carb Ever?
Click to Learn #1 Carb that Kills Your Blood Sugar (Don't Eat This!)
http://thirdpartyoffers.juno.com/TGL3131/54d905c8d415f5c8073dst04duc

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

I have removed the CORS Filter from the web.xml, redeployed, and the behavior 
is the same. Still get the 403 Forbidden return code.

The instructions on that web site say that I should attach source to the jar 
file for Tomcat. It's not clear to me how to do that. How do I select the jar 
file? It's running remotely.

Thanks,
Richard

> On Feb 9, 2015, at 10:47 AM, RICHARD DOUST  wrote:
> 
> Ok. Found the archives for source. Now all I've got to do is figure out how 
> to get Eclipse to look at the source when I'm running Tomcat remotely. I'll 
> review that page you sent the link to.
> 
> Richard
> 
>> On Feb 9, 2015, at 10:14 AM, RICHARD DOUST  wrote:
>> 
>> We are running 7.0.57. I have not tried to debug yet, but am willing to give 
>> it a try. I have gone to the apache site to download the source for that 
>> version but can only find 7.0.59. If you can tell me how to get the source 
>> for 7.0.57, I'll take it down, otherwise, I'll update the executable and use 
>> the source for 7.0.59.
>> 
>> I will try removing the CORS filter from the deployment and see if that 
>> changes the behavior. I'll update this thread when I know the results.
>> 
>> Thanks for your input.
>> 
>> Richard
>> 
>>> On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko  
>>> wrote:
>>> 
>>> 2015-02-06 23:30 GMT+03:00 RICHARD DOUST >> >:
 Hi,
 
 I've got an application that ran well with Tomcat 6.0, but is causing me 
 problems on Tomcat 7.0. The front end is IIS (listening on port 80, 
 passing requests to the isapi_redirect (1.2.40) filter which is configured 
 to send some urls on to ajp13, then to port 8009 were Tomcat is 
 listening), all running on Windows Server 2003.
 
 I know the isapi filter is working because I've configured mappings to the 
 Tomcat docs and manager web apps and can get to them without any problems 
 (via IIS).
 
 I have a servlet deployed to Tomcat that I'm POSTing to via an 
 XMLHttpRequest in a browser. For the life of me, I cannot get it to 
 respond to me with anything but a 403 and I can't figure out why. It is 
 not a cross-domain request, so a CORS Filter (which is installed in 
 support of a rewrite of the application which is underway) can't be having 
 any effect. I have added an init-param to the servlet definition in the 
 web.xml to make sure that it's not an issue having to do with the fact 
 that it's a POST:
 
 
  ,
  .
  .
  
  readonly
  false
  
 
 
 
 In the isapi_redirect.log I can see that the request is being passed to 
 the ajp13 connector. The request is well formed. Everything is as it 
 should be. The war file is configured as it was configured with Tomcat 
 6.0, in terms of its deployment descriptor with the above minor 
 difference. Here is an excerpt from the isapi_redirect log with the 
 request itself preceding what's shown here:
 
 00 00 00  - ManagerRqst>  (Tail end of request XML)
 [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from 
 ajp13 pos=0 len=38 max=8192
 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 
 00 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 
 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 
 01 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
 [text/plain]
 [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] 
 = [0]
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1025): Starting response for URI 
 '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
 [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from 
 ajp13 pos=0 len=2 max=8192
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403):  

Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

[nicksemai...@juno.com]

We just ended up re-keying this cert through GoDaddy with the same repository 
files and the new domain file and it worked as it should have.  Thanks for all 
the replies.

How Old Men Tighten Skin
63 Year Old Man Shares DIY Skin Tightening Method You Can Do From Home
http://thirdpartyoffers.juno.com/TGL3131/54d91d4d799111d4d788bst02duc--- Begin Message ---
On Mon, Feb 9, 2015 at 10:13 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sean,
>
> On 2/9/15 9:46 AM, Sean Dawson wrote:
> > We've had customers who have had issues with Java and GoDaddy
> > certs.
> >
> >
> http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
> >
> >
> >
> http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/
>
> Did
> >
> you read the OP? He's already installed the GoDaddy cross-signed
> certificate.
>
It's also not a Java client problem, since the client in this case is
> Google Chrome.
>

Oh ok sorry - I read it last week and forgot that it wasn't the same issue.
Just wanted to help out anyone else that might have run into the
GoDaddy/Java issue.


> - -chris
>
> > On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Nick,
> >
> > (The formatting was awful on the message and made it difficult to
> > read. I've adjusted it to make it readable and reply-able).
> >
> > On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
>  I have a SHA2 certificate for a RHEL 6 server using tomcat
>  7.0.57.
> >
> > That's an x509 certificate for SSL/TLS, using a SHA2-based
> > signature algorithm, right?
> >
>  Port 8443 is listening, selinux is disabled, and have tried
>  it with 8443 enabled in firewall and with firewall off.
> 
>  After receiving the .crt file from GoDaddy: ran the 4
>  keytool -import commands:
> 
>  For the alias=root, I used gdroot-g2.crt(from repository) For
>  the alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
>  alias=cross, I used gdroot-g2_cross.crt(from repository) For
>  the alias= tomcat, I used the .crt(from
>  GoDaddy)
> 
>  I see all the entries when I did the keytool -list
> >
> > Good. Everything above looks good, except that you need to make
> > sure that the certificates you imported were all the correct
> > ones... thee days, CAs tend to have a variety of intermediate
> > certificates for various purposes: one for code-signing, one for
> > European certificates and another for American ones, an old one
> > with SHA1-based signature, new ones with SHA2-based signatures,
> > etc.
> >
> > Verifying the accuracy of the certificate chain should be a
> > priority.
> >
>  I made this change in server.xml:
> 
>    scheme="https" secure="true" clientAuth="false"
>  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
>  keystoreFile="path to .keystore file" keystorePass="keystore
>  password" />
> 
>  I then shutdown tomcat; startup tomcat.
> 
>  When I go to the URL in the browser with the port 8443, I
>  get this:Firefox: Cannot communicate securely with peer: no
>  common encryption algorithm(s). (Error code:
>  ssl_error_no_cypher_overlap)
> 
>  Chrome: A secure connection cannot be established because
>  this site uses an unsupported protocol.Error code:
>  ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> >
> > What version of Chrome are you using?
> >
> > Do you have access to an OpenSSL library? Can you run "openssl
> > -debug -showcerts s_client -connect https://host:8443/"; and post
> > the (possibly sanitized) results?
> >
> > You could also grab and compile the source of this tool from the
> > tomcat-dev archives and run it against your server:
> > http://markmail.org/thread/tz4z44nfjl7sy2lj
> >
> > This will tell you what is and is not supported.
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJU2M6yAAoJEBzwKT+lPKRYdo8QAKqyY87oXjHy4CkNc3fPjYQH
> IQMRzFrnH/Dgk2g1eO9WXlJXg+4drjmDtsHpRBsJR17nZaDBz282lgVh4x8OUEhW
> tK6eagXHHnwhA8HBCCey5f6EfCF7dMR6AbwLkbhTUN7aym4gYMmQM18q2Nt6jxz7
> qmtHW5GZ4OscqA6MQ5SVT6FckKR83570WakPQsl64JJwCUbC0uwOL9nU654nckNy
> hFiSznDugopfIICrmgHoX6HkAx7lChmCmfpexbUsDZkj/xpPriuvPMPu//sZ4zFc
> euqin0/gDMy76Qr+H0ExHaMKH734vXWgjXTakHg5D/V0C8U4iQEJSBsDWCaXqvDX
> kA+O2s/mYeiqqPVvA4nZ3JrNUQFgZPvOik8ubyCb2+/p7PLL9Hshikgl+sZ4cAW2
> +NfertfDZ483IQKCKN1LKnWZNQ2ofF+jJ1vEoceqV/ybFi8fKipbJ37aU6c7EltL
> h4zJFv86l/irYzVKweGuszX7xX9DwWUu7YdKx4wIVArncb+wrALx3NXF0bI8pMaC
> C5sUoM2EBrOIZZkrpPDPdgr5O+XvWEaARd6eDnCDvZ1xjHcQxiHuVrnglzH3LE2L
> rU6wfg4ZRaX5rMA++