Re: Re: About Tomcat7.0.54 upgrade to Tomcat9.0.1

[????]

On 10/12/17 12:47 PM,  wrote:
> After upgrading Tomcat to 9.0.1,  the local webapp can't right
> work. But in tomcat 7.0.54 is good.

Did you copy your Tomcat 7.0.x configuration file into your Tomcat
9.0.x conf/ directory or did you start fresh?


---> no, i only copied the  section.


Catalina.out >>> out
13-Oct-2017 12:16:55.982  [main] 
org.apache.catalina.core.StandardServer.await A valid shutdown command was 
received via the shutdown port. Stopping the Server instance.
13-Oct-2017 12:16:56.094  [main] org.apache.coyote.AbstractProtocol.pause 
Pausing ProtocolHandler ["http-nio-8080"]
13-Oct-2017 12:16:56.238  [main] org.apache.coyote.AbstractProtocol.pause 
Pausing ProtocolHandler ["ajp-nio-8009"]
13-Oct-2017 12:16:56.294  [main] 
org.apache.catalina.core.StandardService.stopInternal Stopping service 
[Catalina]
Timer Listener Destroyed
DBContext Destroyed
13-Oct-2017 12:16:56.642  [main] org.apache.coyote.AbstractProtocol.stop 
Stopping ProtocolHandler ["http-nio-8080"]
13-Oct-2017 12:16:56.672  [main] org.apache.coyote.AbstractProtocol.stop 
Stopping ProtocolHandler ["ajp-nio-8009"]
13-Oct-2017 12:16:56.682  [main] org.apache.coyote.AbstractProtocol.destroy 
Destroying ProtocolHandler ["http-nio-8080"]
13-Oct-2017 12:16:56.684  [main] org.apache.coyote.AbstractProtocol.destroy 
Destroying ProtocolHandler ["ajp-nio-8009"]
13-Oct-2017 12:16:59.904  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/9.0.1
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
Sep 27 2017 17:31:52 UTC
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server number: 
9.0.1.0
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
Mac OS X
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
10.12.6
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
x86_64
13-Oct-2017 12:16:59.912  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre
13-Oct-2017 12:16:59.913  [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
1.8.0_05-b13
13-Oct-2017 12:16:59.913  [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Oracle Corporation
13-Oct-2017 12:16:59.913  [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
/data/app/apache-tomcat-9.0.1
13-Oct-2017 12:16:59.913  [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
/data/app/apache-tomcat-9.0.1
13-Oct-2017 12:16:59.914  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.config.file=/data/app/apache-tomcat-9.0.1/conf/logging.properties
13-Oct-2017 12:16:59.914  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
13-Oct-2017 12:16:59.914  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
13-Oct-2017 12:16:59.914  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
13-Oct-2017 12:16:59.914  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.base=/data/app/apache-tomcat-9.0.1
13-Oct-2017 12:16:59.915  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.home=/data/app/apache-tomcat-9.0.1
13-Oct-2017 12:16:59.915  [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.io.tmpdir=/data/app/apache-tomcat-9.0.1/temp
13-Oct-2017 12:16:59.915  [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based 
Apache Tomcat Native library which allows optimal performance in production 
environments was not found on the java.library.path: 
[/Users/lijun/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
13-Oct-2017 12:17:00.235  [main] org.apache.coyote.AbstractProtocol.init 
Initializing ProtocolHandler ["http-nio-8080"]
13-Oct-2017 12:17:00.280  [main] 
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared 
selector for servlet write/read
13-Oct-2017 12:17:00.295  [main] org.apache.coyote.AbstractProtocol.init 
Initializing ProtocolHandler ["ajp-nio-8009"]
13-Oct-2017 12:17:00.297  [main] 

Re: About Tomcat7.0.54 upgrade to Tomcat9.0.1

[????]

On 10/12/17 12:47 PM,  wrote:
> After upgrading Tomcat to 9.0.1,  the local webapp can't right
> work. But in tomcat 7.0.54 is good.

Did you copy your Tomcat 7.0.x configuration file into your Tomcat
9.0.x conf/ directory or did you start fresh?


--
From: (Carl.li) 

 




-- Original --
From:  "Christopher Schultz";;
Date:  Fri, Oct 13, 2017 10:41 AM
To:  "users";

Subject:  Re: About Tomcat7.0.54 upgrade to Tomcat9.0.1



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

,

On 10/12/17 12:47 PM,  wrote:
> After upgrading Tomcat to 9.0.1,  the local webapp can't right
> work. But in tomcat 7.0.54 is good.

Did you copy your Tomcat 7.0.x configuration file into your Tomcat
9.0.x conf/ directory or did you start fresh?

> --- server.xml host configure
> 
> 
>  appBase="/data/wwwroot/seshenghuo/seshenghuo/htdocs/jsp" 
> unpackWARs="true" autoDeploy="true" deployOnStartup="true">
> 
> 
>  docBase="/data/wwwroot/seshenghuo/seshenghuo/htdocs" 
> reloadable="true" privileged="true">

Bad: don't put  elements in your server.xml. I honestly
don't really understand why we still allow this...
> Exception org.apache.jasper.JasperException: /jsp/web/index.jsp
> (line: [1], column: [1]) File [] not found

Hmm... that's not really much help. How about:

> Note The full stack trace of the root cause is available in the
> server logs.

Can we get the full stack trace, including any "Caused by" lines?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJ8MACgkQHPApP6U8
pFj2nhAAnk9DINqYraNidTI2J70ksUH/3WLdyriMvTAPuoXvq9u99ZItioDcsoQ6
CxnsmxEnKHAtGe3O3+5E/7EKqJPpKdW57dA6mZhSBqoacXegnNxHbwVO8ovwB3jw
1O2R5k8HjpTWWyc4cKaH4FMH+unfQ5xEkrZwcLutyz0cGPOotl/Ib9p0B3l2LyZb
Q6MXe2Ih+SUtrx6FR3XYA9jZBamAFSSiYFNRHI65LlpOhyL9Whrmuo/B1rJh5G4U
EN+bZTGchNDWqGs5yhsspSFMsUtDz2tT9I/i8YdbIgLzHzEJf8TdTtRlN2nFb1kf
uRwtSq9eUY6vURGLlrJ1kgvdRJ30w3HktKZqgEVjXWIrXJF2KRvgOyog9Fkt/47I
a/+4FMp0gU1AtV7Y46ueLgkAFBYgfoKE8OyqX2a/dAVKrZHspbxl9vC/sUDp1Uoh
O9mkHUwM3VC2GsGwZPMl+WMZ3Uey6i3gE5pBxrl8dw7i9slpeAs1rcXKSq7+tftb
f+tEkzijtYYbKB6YycwAETtyTglzutIYgAbt/Cn75x8l9JFT4WKr1XTweLol7NNv
3bgm4MhEgn40uyIqXludZDPnLtR3qCBRUH/Aqg0Yx7gCFMuKLsphsXj/fdr1rCsp
qfTZGC+fLhcBCnuV7B+ETGqSGR4zoojhomnLH1W4hBFIMVd6x4M=
=oIKF
-END PGP SIGNATURE-

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

Re: Basic question related to NIO connector and Async servlet processing

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Saurav,

On 10/11/17 8:56 AM, Saurav Sarkar wrote:
> I have got a basic question related to usage of Async servlet with
> tomcat NIO connector.
> 
> I want to use Async servlet with Non Block I/O as per servlet spec 
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm?lipi=urn%3Al
i%3Apage%3Ad_flagship3_pulse_read%3BmL0Q5Y7ESTy4lpYPU%2Br77w%3D%3D
>
>  Such that the http worker threads are released and the container
> threads won't be sitting idle for I/O operations too.
> 
> I am on Tomcat 7. As i understand the default tomcat connector
> (BIO) is a blocking one and is on a thread per connection model. I
> am not clear on whether using async Non Blocking I/o in servlets
> won't suffice ? Won't the http worker threads be released here or
> will it be held for the lifetime of the connection ?

You can't effectively use BIO with async, at least not the way you
actually want to use it. You should switch to NIO if you want to use
servlet-async.

> NIO connector will use request per threads or allocate threads
> when processing is required .Will using NIO selector only release
> the http worker threads if it is used in conjunction with 
> Asynchronous Non blocking I/O servlets ?

That depends upon what you mean by "release" and, specifically, /when/
they are released.

With the BIO connector, HTTP keepalives can tie-up a connector up to
the keepAliveTimeout without accomplishing any useful work. This
happens ALL THE TIME -- clients make a keepalive request and then
never bother to close their connection cleanly. So the server wastes
thread-time waiting for another request which never comes.

The NIO connector (and APR connector) puts the connection into an I/O
selector and waits for an interrupt from the OS/JVM while the
request-processor thread goes back into the thread pool.

When doing servlet-async and Websocket, things get ... more complicated.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngMdMACgkQHPApP6U8
pFjwiw//UeN1W08AId+OcVUc2ZMnzZZZJLnu6RhY+yO50avZx3PhvzGxrHZTfBRD
FFRJRBOCo/1TFacQxUjFXr4Q9tkdcABcN6cVj6f7tJh4S55/jxEeHkg8UGNQe31V
9N6GpUIzRq/WuDFJQRfwJnpOQRVs+DXVIrWWD8RqQ6BooHkt2mUl0u7oYRxcLcQ1
SD8tEK1O1LiJ1gwNWs5Cx1d7s/6mE2tSxKvKH94yr1MvfdChj51vrc7JI3+gfdwa
V6FWItVoIuG4rNqFsthaKiXswvqyGC+gzPG9Jn7aEh0Xd2rzCAX+E9GMM7aKMHEL
QOu+gFm897eRhL4ueBDBxl3MY1R/xD5JEIDeuO82gbmM8xcm7sSqWs2TOazFC5xs
JOdo52xS38RHgRf+eSQ7+KMmZYznYbUscJMokTHYWU/twC7tSzmO4rYB2EEPNTEB
czNyxv4MbWCaQjOunYeFMp2byEFmLyLu2e+jBDPdmPsjMgpduQ35E4spfaYRaCc0
5J8HRaQ4s0amy6b9s/j95pFvYVRlaPRN7ebNMtT/BhoakKXk+ugpNsnCI21zChAJ
aKOdPzb5RU90Qm7mDXeRFqggfI5S1w507WlQZp6bZG6WZ2oz0ykF87WHHQP8C5F4
AvSvTe32zDpmCt0rS7+VgTGBNL/VGLv8r8S/0eLjldA0LDASkTA=
=vSrb
-END PGP SIGNATURE-

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

Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 10/11/17 5:21 PM, Chris Cheshire wrote:
> Working on a migration from 7 to 8.5, and in it I am now using the
>  tomcat dbcp, instead of apache commons dbcp.> I have found that
> with no other changes to the db code (except the factory param for
> the resource), it is working fine other than there is an implicit
> commit happening when I close a connection, even with autocommit
> turned off in mysql config, resource config AND in my code.
Your complaint is very close to my heart, here. <3

Back in 2003 or so, I posted roughly this exact question to this
mailing list with a little less ... diplomacy, shall we say?

> try { this.dbConn = this.dataSource.getConnection(); 
> this.dbConn.setAutoCommit(false); 
> this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMIT
TED);
>
> 
}
> catch (SQLException ex) { throw new DAOException("unable to get
> database connection", ex); }

I'll bet you've had this problem for a really long time, but just
didn't notice it until now.

The core problem is that you have autocommit=false in your
configuration and autocommit=true in your code. If an exception occurs
and you don't rollback the transaction, the connection pool will reset
all of the settings to your configured settings (including
autocommit=true). Setting autocommit=true when autocommit=false
commits the transaction, which is SUPER surprising to anyone who
hasn't read the Javadoc[1]

Technically, this happens whether you encounter an exception or not,
but it's fairly rare to have code that intentionally does this:

conn.setAutoCommit(false);
// UPDATE ...;
conn.close();

So, given that this is usually an "exceptional" situation, it's your
exceptions you need to carefully handle. In fact, you need to do more
than you are used to doing.

Have a look at this post I did years later when related questions kept
coming up on the list:
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin
g-pooled-jdbc-connections/

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngMBoACgkQHPApP6U8
pFhdjBAAl2u3lxKhrjKdmtjUgtYp0/gOfTPq7jXjdgZBrkSNh9q6I8dJ6gQOsECV
TkCQ2LH8tAUpuUYWCt7QJRLQPVAuwrzplue1InlTFCS8I1b/WK7vQk93teB4I0Ia
HKaC4RGGtgKgS//PsCRxDdFgo0Hzr+hA+nte1qFytmla8ZRZjimbz5EnWJpNwYoU
XjEjhaF6wdVOHP8zKU9/CIc3XQKC1kfQb9Rodb9SZTpjFDTw12NsBjEXG5evY8XJ
A2PPxHPiRdyyHq2R1MDWGFWdSdCsY4pFq4nvNExEuIuHg1/C+GlGUENLH3MiJNPY
minxeaKykVfmUd2zJvWjxmhrdw8nHT3ThtAHA0BgU7thBCenANFbSBxx7+39Jxg/
eDEW4dEqOP3c/ZvifpMrGxjJ0zXBXDu7Jik4KFEzMWI8oaAl3hSSDwEe7FEJE41Y
lDv+LjcBgDwSHLfTbau+0xJx79wAKTAFY7v7uGujUgDZqWsRG1znyZx+OuZnbWxQ
JSbQSJ3pOMerybeJMuHx1a4y+HwA4t0GtLigeRMeyFvTqqtfCVasr3ONMh22XYIU
OORbLADRwjbqYnswvxRC06FfKvU8AhNwuybt/XzHrTfURuIZWx7GRycMlaEMaUdS
OdWlW6Zf3+fWfUxg05zIX3q2Ug4h2O1zW+ccPOrs5bswE9EEAZM=
=eyik
-END PGP SIGNATURE-

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

Re: Enforcing server preference for cipher suites

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Harish,

On 10/12/17 10:55 AM, Harish Krishnan wrote:
> Thank you all for the help and responses. We figured out what the
> problem was. What I did was correct in terms of the attribute
> setting, the tomcat version used and the JRE version used. However,
> I did not realize our JRE is running in FIPs mode using RSA BSAFE
> as the crypto provider.
FIPS strikes again!

In this case, it's not really FIPS's fault, it's RSA's BSAFE. Anyone
using RSA's BSAFE these days ought to lose their job. Plow that thing
under with salt and use a trusted crypto provider (lol, Oracle, I guess)
.

> When I tested and ran under standard JRE, then the server cipher 
> suite order was preferred.
You are probably using an ancient version of BSAFE. Your random
numbers are probably all ones. Seriously, you need to dump BSAFE.

> Now I will have to look into what RSA library is doing here.

Leaking like a sieve, probably.

> Probably they are setting that Java API too which could be 
> overwriting our setting in tomcat.

If that crypto provider is in use, then it'll likely affect the whole
JVM. It just occurred to me that Tomcat doesn't have a setting for the
crypto provider to use for TLS itself... only for the various
"stores", etc. We probably ought to add that, and then you could
choose "JSSE" as your provider and avoid BSAFE.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngLCgACgkQHPApP6U8
pFjanhAAkTNcGk5/X6b9aK2gYcSDdTjkE879XA77KGYwWDF2L01jtSdF7ejnCcuN
4lfivY/V5TaiKv0EZrU1YVC2psBZVK5CjfsCIfUZe5gOmqRRtxm8vRARULOY31oQ
tm4Hf3PHVXuKa/ZBQutLFOolJo7IhaYP3CtBqE+i7OWSlyy0dsqdqO40z9+vzt2n
DBiMRXl0Y2HGCeRsm0owdsFFDqA/j0xcCTBjgckgR6TcnRPc926FZVmr+q53DEQ1
rYVo3Kfum7AnLP3y4rVT0SsxavjI48aXqCLKcM9RzRJ//D+p9teOeiHiUtu4CzHY
aQmkV22N6LC3M5uBwNNU1xXr62SNiarqY7euurPhPcOkbQSi4ckfknh48JzenQ41
Ws7XvuLGOmTcLOv+rsKYjBd5s6IxuBH/+k5MfttPQaZ8mHAieMjEnVszmjZon2rE
Mqqcd+C5Z0q2/X9wUAwNAD3muQTzx2A8C3uucJHVygvwNy76UCUCoyLakQ98/8WL
3SKN2l3EddObdi4OUrfga80ZTLf0AnBoflmKz+2UAbP3Xit++XHBs5dBgvN51Tji
d6IdBRJpSq/njZmnSGQYJ/4o07v31YgLjh+xZTS+8wxm5H3C4V6/IuWlsnYPZWi5
YQRe0GPZw54IuLs9WZG6AbNcAzhGOW+OBIMGbzSKQukeLAVpjws=
=KUgn
-END PGP SIGNATURE-

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

Re: installing certificates

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 10/11/17 8:48 PM, Adam Pease wrote:
> Hi Chris and all, I was able to get my system running based on the
> instructions at 
> https://community.letsencrypt.org/t/configuring-lets-encrypt-with-tomc
at-6-x-and-7-x/32416
>
> 
.  I clarified them a little and put
> them into the context of installing my open source project at 
> https://github.com/ontologyportal/sigmakee/blob/master/Security.txt

Note
> 
that you are wasting your time generating your own RSA key, then
using LE to generate the CSR, etc. It's much easier to simply let
certbot do it's thing and then throw everything into a Java keystore
(if you must use JSSE instead of APR/OpenSSL).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngKWoACgkQHPApP6U8
pFgiRw//SdXw7Yvh0fdNPtF5U+mgRNv3NqaduuCTi/W0bO/jRAjaY7mdHW1ykWjx
W2+p6TPAtADCd71KdebBcTqFaxEOhvQiClngjSah8ysPFH2lEHiRagx90ZMslmgU
JC3wlUgU8/iMlH8O1tCR3A149f7SmxaeMlbZ9TSNm5kdbQ5ghFfKYiENOtgPvV+P
87GrPN3QYPQ8c6aWUOxWpEYMxpmXQrvF1igLahG14E0Z3ViNx+OW3+oRDKJnNWSg
w0NoVmJR+b1RsF425xhXMq8OkvoewciIVYOepTDP2lH6UXD8TXb3tVH4O/ioVCKb
SSfFZBHTzfThRxjwp18VZXzwEYO2ZCcmpTIqd5L5SFkMeMfgDo0ifhQSRiScLlky
t4gTc+bQQqLdw/51xws0sOzOZGRbx5HeNQSr4Jt+2PqyPEQWv6U/1qD7zwBv+nlp
uQsH8MpWJrhuGaeOAGx0pXQVrJHVdjTEz59fnfuHPSwvy55SawEpryLWGGBXMDqm
YMBv0kxXgfzDUwQrWHn6jOXSxG0q2CwiyJmxaLh2RDVXFKnTcFzy1z3nHFhjzRUx
GpAvUIF0Fm7JkLfBxxMLws0tdizQebqLMO5SOHYtVw3fpJ4YZCq7Vvm1ByyhTR/g
2lzwv7nCVmMyKAJw/CFMZ8nlpOU2OpqL07kV1WhnCHh0dco1rWM=
=Sy3s
-END PGP SIGNATURE-

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

Re: installing certificates

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 10/9/17 6:13 PM, Adam Pease wrote:
> Hi Chris, Many thanks for the quick response!  There's a lot of new
> terminology (to me) to all this and it's quite confusing I'm
> afraid.
> 
> I tried Let's Encrypt just now but since I'm running Tomcat sites 
> either I'm not doing it right, or it doesn't know how to verify
> domains when they don't answer on port 80.  So I get "The server
> could not connect to the client to verify the domain :: Timeout" 
> Following the process at "gethttpsforfree.com" resulted in two
> long hex keys: one titled "Signed Certificate" and one titled
> "Intermediate Certificate".  I'm not sure what a "server
> certificate" is.  Is that a public/private key pair that I
> generated at the beginning of this process with
> 
> openssl genrsa 4096 > account.key
> 
> or what I did at the beginning of the tomcat instructions
> 
> $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
> 
> But that generates a .keystore file which is already a parameter to
> the failing command.
> 
> I really appreciate your help.

Have a look at this page:
http://tomcat.apache.org/presentations.html

Search for "let's encrypt".

There's a ton of stuff in there that you don't need, but the basics
are in fact there, including (IIRC) every single command you'll need
to execute in order to get yourself a certificate signed, installed,
and running in Tomcat.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngKLsACgkQHPApP6U8
pFi2pQ//SAjMDzTHWMT/Eg3HDs7+Es++0e4ysYjBNFP2+pq/krtaF6T4mUIVscBq
3KCNdaBIjM/WDrHCwD41G3rZ7OWeTXb4mPXKMeyYzVUdcZKNe/GvmA0rCgV345Uy
o+21S0SYUI4sH8Cuh8h44WCzScyzRvFmrwIzPuC+lo11klk3C1GSZAu9achjKfjr
Q5DqLlpfQUu3RL17HIy6JsFogTU3qhVhgzUIxWl2c/SBE3p1FvCMvCx2HNA57/1D
iakOX5smGW/NU9B2RiWf9LlXdwH4qvwfmTXbqe90ewww3DyUQMAK2JvoydcaIL2+
g8fjtKwTBsswRSsXpOXeXFDK8f5dpeAvNkJXS//Vu6oyt9gg3MYf3CUd3+wVoAaL
XZ/Tnx2lSjwHibwf1amzvgPTqFqXlowIaXrnafk3eKdCawQCEUvJrcvlpqviZVHS
BgQR0ebphM0Q4s+Nro8lfOSo9v1ekFLxyU0wXQt6qVsQ8RYTyaDZ8szHvis/cdOh
I1srYMkRPJjcK97gb1zF1064SH4uKbwo9cTxGSichocUQZzET1BVIVSnAA7wLlk9
C/MgHRAB620a03MWeA1tDj48mccHiX94T6LlQAJGccAESPyZinvWg2MSfqkRCxct
8YfZTHfPYNo3LrAXYrd4fa17VUhnjTXwLf3JgUcy9QAJ1urTYOA=
=2f+C
-END PGP SIGNATURE-

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

Re: About Tomcat7.0.54 upgrade to Tomcat9.0.1

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

小网,

On 10/12/17 12:47 PM, 小网 wrote:
> After upgrading Tomcat to 9.0.1,  the local webapp can't right
> work. But in tomcat 7.0.54 is good.

Did you copy your Tomcat 7.0.x configuration file into your Tomcat
9.0.x conf/ directory or did you start fresh?

> --- server.xml host configure
> 
> 
>  appBase="/data/wwwroot/seshenghuo/seshenghuo/htdocs/jsp" 
> unpackWARs="true" autoDeploy="true" deployOnStartup="true">
> 
> 
>  docBase="/data/wwwroot/seshenghuo/seshenghuo/htdocs" 
> reloadable="true" privileged="true">

Bad: don't put  elements in your server.xml. I honestly
don't really understand why we still allow this...
> Exception org.apache.jasper.JasperException: /jsp/web/index.jsp
> (line: [1], column: [1]) File [] not found

Hmm... that's not really much help. How about:

> Note The full stack trace of the root cause is available in the
> server logs.

Can we get the full stack trace, including any "Caused by" lines?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJ8MACgkQHPApP6U8
pFj2nhAAnk9DINqYraNidTI2J70ksUH/3WLdyriMvTAPuoXvq9u99ZItioDcsoQ6
CxnsmxEnKHAtGe3O3+5E/7EKqJPpKdW57dA6mZhSBqoacXegnNxHbwVO8ovwB3jw
1O2R5k8HjpTWWyc4cKaH4FMH+unfQ5xEkrZwcLutyz0cGPOotl/Ib9p0B3l2LyZb
Q6MXe2Ih+SUtrx6FR3XYA9jZBamAFSSiYFNRHI65LlpOhyL9Whrmuo/B1rJh5G4U
EN+bZTGchNDWqGs5yhsspSFMsUtDz2tT9I/i8YdbIgLzHzEJf8TdTtRlN2nFb1kf
uRwtSq9eUY6vURGLlrJ1kgvdRJ30w3HktKZqgEVjXWIrXJF2KRvgOyog9Fkt/47I
a/+4FMp0gU1AtV7Y46ueLgkAFBYgfoKE8OyqX2a/dAVKrZHspbxl9vC/sUDp1Uoh
O9mkHUwM3VC2GsGwZPMl+WMZ3Uey6i3gE5pBxrl8dw7i9slpeAs1rcXKSq7+tftb
f+tEkzijtYYbKB6YycwAETtyTglzutIYgAbt/Cn75x8l9JFT4WKr1XTweLol7NNv
3bgm4MhEgn40uyIqXludZDPnLtR3qCBRUH/Aqg0Yx7gCFMuKLsphsXj/fdr1rCsp
qfTZGC+fLhcBCnuV7B+ETGqSGR4zoojhomnLH1W4hBFIMVd6x4M=
=oIKF
-END PGP SIGNATURE-

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

Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vamsi,

On 10/12/17 11:06 AM, Gali, Vamsi A wrote:
> This issue is now RESOLVED.

Great.

> On IHS (IBM HTTP Server, IBM version of Apache Webserver), we only
> had 2 TLS ciphers that are no compatible with Tomcat TLV1.2. So I
> added '' TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256" to IHS httpd.conf
> by looking at this:
> https://www.ibm.com/support/knowledgecenter/en/SSEQTJ_8.5.5/com.ibm.we
bsphere.ihs.doc/ihs/rihs_ciphspec.html
> and IHS can communicate with Tomcat W/O any issues. Woohoo!
> 
> The reason I picked the above cipher is because it's one the list
> of ciphers tomcat's JVM supports.

I would recommend that you configure IHS to support *multiple* cipher
suites instead of just the one. I would also recommend using GCM mode
instead of CBC mode if you can do so.

> Igor, I couldn’t use one of the java based cipher tool so used a 
> small script to get a list of ciphers available for a jvm(this can
> be used for any Linux server as long as openssl is available):> 
> #!/bin/sh for v in tls1_2; do for c in $(openssl ciphers
> 'ALL:eNULL' | tr ':' ' '); do openssl s_client -connect
> SERVERNAME:https_port \ -cipher $c -$v < /dev/null > /dev/null 2>&1
> && echo -e "$v:\t$c" done done

The output of the above command has absolutely nothing to do with the
cipher suites Java supports. In order to determine what Java supports,
you must use a Java-based tool.

(Unless you are using APR, but you are clearly using Java BIO.)

> I executed above script to find out a list of ciphers on Tomcat's 
> jvm and based on that I chose to use 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 on IHS.> I appreciate all the
> help on finding me the true issue!

Glad you got it done but it's clear there is still some confusion.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJvYACgkQHPApP6U8
pFgqwBAAngdJEPfKu44DfOrRdfnkjNRNRh8J+xfwEgAwJh+esusDUL/vKyXPffpQ
8HcjkYAq6dWLdEaHSZMYksrK78UrelBLWfdss8WTfDwT82/1lSY1/CpAaO+yK8WF
VStRmOdBqHDVdumbAUGZthcvhN5JnIQwril9JfAyofs08VnjhZ4CbSfcKYdKXyIP
0ELbdq8e/4M8cOZcq+99wPFt+V7D037LsHXbd3aPGAk26AFzlEl5uqX4lzsa/k+Q
uaO81P4nX5F+3Y2WuE6gfBlRi3xUplW1yQZ73K+Wg3rS7Tgd3b4+V2eKP9GyEuoD
zFE8OtfgcjCDv8nlpJKQOQU745VDaFC4y+cteiImhRHgD7OgnXregDxiuaz8RVyB
mvIzMbkevySchrWhI/yB5DMmPs33RfyBKsPxOkdhpdQEFQ7HvqKjsFIikcVSS6Um
yjMky8JouWZzBLr9FZ+KYjTSZWtxXA1xQiseBS08aWdyUh09NTpBJfE8pn6FBExq
8LxHeKBWCyW3ZNbbKp9cT/thQ4axYbFxhWtJr4UdDM6GYcBVmt1VVarWGfEd8dui
PehjgnrkuQF7mCXRWR54mYZp+k28xr1336UTj0OTgUxoyoqpwDoSYfKNn3Bt+/53
otZ8gRFYS0ynWStnQDc4WU9AYXLAPoKdfZUZxdnUYEbAUhlcWOM=
=Jsf+
-END PGP SIGNATURE-

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

Re: URL-encoding and "#"

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/12/17 8:44 PM, James H. H. Lampert wrote:
> Question:
> 
> The application we're developing has a suite of web services
> (RESTful, Swagger-based), and at least one of them can accept a
> pound sign ("#") as a URL parameter.
> 
> Several months ago, with the application and all of its services
> running on Tomcat 7, it was accepting a plain, naked # in the URL.
> Now, running on Tomcat 8.5, it's returning an error message
> ("HTTP/1.1 400").

No client should ever send a naked # to a server. It's a violation of
the spec, full stop. That isn't to say that Tomcat should fail in any
particular way, but Tomcat is well within its rights to say "a # is
not allowed in a URL, so this is a bad request".

> The developer (in a different time zone) has explained about 
> URL-encoding, but hasn't said whether there was anything in his
> code to make it stop tolerating the naked # sign.
> 
> Did the change from Tomcat 7 to Tomcat 8.5 have anything to do
> with this?

Each version of Tomcat gets more and more strict about the garbage it
will accept from clients. This is done to improve the world as a
whole, and also improve security when it comes to things like
converting URL paths into filesystem paths, etc. Strictly speaking,
everything should *always* be safe, but it helps to stop The Badness
at the earliest opportunity.

> And if so, are there any other common ASCII characters that used
> to be accepted as characters, but now have to be URL-encoded?
Anything in the URL spec that is allowed should be allowed. Clients
should expect that anything not mentioned in the spec would be
rejected by a compliant server.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJRsACgkQHPApP6U8
pFhqMg//cP4U9z0v8AzkdGRfWJilIAVdsgbA8fdfqTM0f542GzHo4tWidx6F89zK
y2oVxz9Fr4RQev2Dgr5DyPrJnv2JYufe2S3AxBltA1jQQCu6GnqEjgzxlvmrGY05
hhrBYBBOgBudgLXcK4bHuoIk+W5ke1Hc1n94WqyVDq2EJZUibKLJLGo3nsAItBcS
a7jFitbzAQT/0fX/Nzo/LFanNNLenOkoKxZA0KyqzDYiwOGcsLLukOIV1AOiWgEU
cy4dFhYkixoi8lfs5SjivNknp5tDJSq6Rf3UYChkXUcwQUTVA45AecRWvaEihwjr
fFN91h9AVKXoVBVNjPYLKS7K7ODahR6oLNqta/2aji4QgCBnyfrPvopIG7e6fbM8
BYo+MfpbrVi8b7ZL69d2Cl8+/6MmcUbWfuPzZsBm9Mg7tdza13NQ0vin3uyv0y6N
73ytO57G1CVfFK3T8v6giEMt6URpBzviF1PK0gTpBImZO13eXYVO5D8E0cXp0Q2d
cTSC120wgwIhN4tBlrf2asjdut+0K7cpYpuAQVHFCacedhdTxDPR+OoWo4zRoYuI
3D776j6OoyxGCmU2GNR9kNK8q3fuVouplCapdRKPPqlbskCzmfb70SjevVGX3sAT
/OwMwonndlCQoFOob4zg03a2rnKMritVcflffeYmih0Xm+UU7QY=
=SwD9
-END PGP SIGNATURE-

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

Re: Tomcat 8 APR/openSSL Issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Syam,

On 10/8/17 2:27 PM, Syam Pillai wrote:
> Thanks Chris, yes you are right they messed it up. I will also file
> a complaint with them.

https://forums.aws.amazon.com/thread.jspa?messageID=809159
https://forums.aws.amazon.com/thread.jspa?messageID=807909

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJDcACgkQHPApP6U8
pFgdvg/+PNvw14upKjf10n6cJWozaDdG2RY251DY9I3gHyTJ+Cv97kQWNFB7xAcL
tKxOxwyWY7yYri37OdoBGGiTXKyqzbgF7oQB7A9pE0jitAFeAdaHXZQqVG/QCzIW
cWuttuCQZjCfXS6eMKG/cjIBcp+gHRRc32I4CDxE7CNeMZT9omRTghsr4NJck4EE
2wOweJ4KZIGyxE36mDa9jg7tt4683rue55tRz7aHG/Iutyh8raGovw4l9SvZTZYL
9VMnB+gawKrlAOMoe0So1ZBeGLpa10ZE6AqaYVn3TAGGwVvFbAgxYbql4YWnW4wA
4n2ZI4HijV16X71T9JKxhqMfmopgt8GdO/v3UAVQxPIV0vShSZSFyB8tXsd6/Hug
uClIozRJJev/OQbupOjQSHF7qR4R33fZyB0nhC/XKFfp18qt0DT1kNAe03aXWFRS
cAk7Blt4tf5o18wqWCyGWviuTwWU+3zGcHbzoc3V0NcqOW3TlUgI99rmS+APNvf4
oUGpJfKhbfUW5LPHrFePxBNKBlguM546df67YKQ/qy3TlsQIczZg7R2ufwOpEWTm
duPhieXnSmbt+A1rjpepDRModm0MpEqFlm7R9GyW1ZkD0x6gcd+vk75ahaY+vA1R
pj5E9NufMav4axX2F/oV1bmYM0rbCEYY4OvpHeCrSFrB5AeaIQc=
=T7CX
-END PGP SIGNATURE-

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

URL-encoding and "#"

[James H. H. Lampert]

Question:

The application we're developing has a suite of web services (RESTful, 
Swagger-based), and at least one of them can accept a pound sign ("#") 
as a URL parameter.


Several months ago, with the application and all of its services running 
on Tomcat 7, it was accepting a plain, naked # in the URL. Now, running 
on Tomcat 8.5, it's returning an error message ("HTTP/1.1 400").


The developer (in a different time zone) has explained about 
URL-encoding, but hasn't said whether there was anything in his code to 
make it stop tolerating the naked # sign.


Did the change from Tomcat 7 to Tomcat 8.5 have anything to do with 
this? And if so, are there any other common ASCII characters that used 
to be accepted as characters, but now have to be URL-encoded?


--
JHHL

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

About Tomcat7.0.54 upgrade to Tomcat9.0.1

[????]

hi, 


After upgrading Tomcat to 9.0.1,  the local webapp can't right work. But in 
tomcat 7.0.54 is good.
---
server.xml host configure








  

   


  


---
webapp dir.



- htdocs
  + jsp
  + static
---
jsp source file


<%@page language="java" contentType="text/html; charset=utf-8" 
pageEncoding="utf-8" trimDirectiveWhitespaces="true"%>

>

<%@include file="/static/v1.0/inc/meta.html" %>
<%@include file="/static/v1.0/inc/rem.html" %>
SE
<%@include file="/static/v1.0/inc/css_common_gm.html" %>
<%@include file="/static/v1.0/inc/css_common_dm.html" %>
<%@include file="/static/v1.0/inc/css_web_index.html" %>
<%@include file="/static/v1.0/inc/stat_code_header.html" %>


<%@include file="/jsp/web/inc/header.jsp" %>

  


  


  

  

<%@include file="/jsp/web/inc/footer.jsp" %>
<%@include file="/static/v1.0/inc/js_common_j.2.x.html" %> 
<%@include file="/static/v1.0/inc/js_logic_d_web.html" %>  
<%@include file="/static/v1.0/inc/stat_code_footer.html" %>





---
exception



HTTP Status 500 ?C Internal Server Error


Type Exception Report

Message /jsp/web/index.jsp (line: [1], column: [1]) File [] not found

Description The server encountered an unexpected condition that prevented it 
from fulfilling the request.

Exception
org.apache.jasper.JasperException: /jsp/web/index.jsp (line: [1], column: [1]) 
File [] not found
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:292)   
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:98)
org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:345)  
org.apache.jasper.compiler.Parser.addInclude(Parser.java:396)   
org.apache.jasper.compiler.Parser.parse(Parser.java:138)
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244)  
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:127)
  org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:202) 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:384)  
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)  
org.apache.jasper.compiler.Compiler.compile(Compiler.java:345)  
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603) 

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) 

org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)   
javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)  
com.seshenghuo.filter.DefaultCharsetFilter.doFilter(DefaultCharsetFilter.java:36)
 
Note The full stack trace of the root cause is available in the server logs.


Apache Tomcat/9.0.1









--
From: (Carl.li)

RE: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[Gali, Vamsi A]

This issue is now RESOLVED.

On IHS (IBM HTTP Server, IBM version of Apache Webserver), we only had 2 TLS 
ciphers that are no compatible with Tomcat TLV1.2. So I added '' 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256" to IHS httpd.conf by looking at this: 
https://www.ibm.com/support/knowledgecenter/en/SSEQTJ_8.5.5/com.ibm.websphere.ihs.doc/ihs/rihs_ciphspec.html
 and IHS can communicate with Tomcat W/O any issues. Woohoo!

The reason I picked the above cipher is because it's one the list of ciphers 
tomcat's JVM supports. 

Igor, I couldn’t use one of the java based cipher tool so used a small script 
to get a list of ciphers available for a jvm(this can be used for any Linux 
server as long as openssl is available):

#!/bin/sh
for v in tls1_2; do
   for c in $(openssl ciphers 'ALL:eNULL' | tr ':' ' '); do
 openssl s_client -connect  SERVERNAME:https_port \
   -cipher $c -$v < /dev/null > /dev/null 2>&1 && echo -e "$v:\t$c"
   done
 done

I executed above script to find out a list of ciphers on Tomcat's jvm and based 
on that I chose to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 on IHS.

I appreciate all the help on finding me the true issue!

Thank you,
Vamsi Gali


-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Thursday, October 12, 2017 10:05 AM
To: users@tomcat.apache.org
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL 
proxy connection

On 12.10.2017 15:33, Gali, Vamsi A wrote:
> :)
> IHS is IBM HTTP Server.
>
> Thank you,

Thank you too. I feel a lot less like a dummy now.
And after reading a bit on "IHS" now, it would seem that this is at least 90% 
Apache httpd 2.2, which may make it clearer to other people that maybe they 
could help too.

>
>
> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
> Sent: Thursday, October 12, 2017 9:32 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not 
> establish SSL proxy connection
>
> And for the rest of us dummies trying to follow this conversation, what might 
> "IHS" be ?
> Whatever Google returns doesn't seem really relevant.
>
> On 12.10.2017 15:25, Gali, Vamsi A wrote:
>> Igor,
>> Thank you for suggesting me to turn on the ssl dubug. We are using Java 1.8 
>> which by default uses TLS1.2. Looks like both IHS & Tomcat are using tls1.2 
>> but there is a cipher mismatch. We have Tam directly connecting to Tomcat 
>> and the connectivity works w/o any SSL handshake errors. Hence, I'm 
>> suspecting IHS and will be trying by adding same tls1.2 ciphers that 
>> Tomcat/java supports.
>>
>> Thank you,
>> Vamsi Gali
>>
>>
>> -Original Message-
>> From: Igor Cicimov [mailto:icici...@gmail.com]
>> Sent: Wednesday, October 11, 2017 7:33 PM
>> To: Tomcat Users List
>> Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not 
>> establish SSL proxy connection
>>
>> On Thu, Oct 12, 2017 at 9:17 AM, Igor Cicimov  wrote:
>>
>>> On 12 Oct 2017 8:25 am, "Gali, Vamsi A"
>>> 
>>> wrote:
>>>
>>> The debug log produced following & it's evident that handshake is 
>>> failing due to no ciphers suites in common.
>>>
>>> Allow unsafe renegotiation: false
>>> Allow legacy hello messages: true
>>> Is initial handshake: true
>>> Is secure renegotiation: false
>>> http-bio--Acceptor-0, setSoTimeout(6) called Ignoring 
>>> unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>>> for TLSv1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1.1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1.1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1.1
>>> Ignoring unsupported cipher suite:
>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>>> for TLSv1.1
>>> Ignoring unsupported cipher suite:
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>>> for TLSv1.1
>>> Ignoring unsupported cipher suite:
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>>> for TLSv1.1
>>> http-bio--exec-2, READ: TLSv1.2 Handshake, length = 57
>>> *** ClientHello, TLSv1.2
>>> RandomCookie:  GMT: -2042962343 <(204)%20296-2343> bytes = { 199, 
>>> 95, 13, 144, 113, 194, 145, 53, 176, 117, 165, 93, 196, 76, 17, 104, 
>>> 214, 95, 96, 238, 97, 6, 240, 239, 53, 188, 180, 41 } Session ID:  
>>> {} Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 
>>> 0x56:0x0, SSL_RSA_WITH_RC4_128_SHA, 

Re: Enforcing server preference for cipher suites

[Harish Krishnan]

Thank you all for the help and responses.
We figured out what the problem was. What I did was correct in terms of the 
attribute setting, the tomcat version used and the JRE version used.
However, I did not realize our JRE is running in FIPs mode using RSA BSAFE as 
the crypto provider. 
When I tested and ran under standard JRE, then the server cipher suite order 
was preferred.
Now I will have to look into what RSA library is doing here. Probably they are 
setting that Java API too which could be overwriting our setting in tomcat. 
Anyways, that's our problem to look into.
Thanks again for the timely response and help!

Sent from my iPhone

> On Oct 10, 2017, at 10:26 AM, Konstantin Kolinko  
> wrote:
> 
> 2017-10-09 19:31 GMT+03:00 Harish Krishnan :
>> Hi All,
>> 
>> Need your expert input here.
>> Not sure what I am doing wrong,  but I cannot get this server preference 
>> cipher suites feature working.
>> 
>> My setup:
>> Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute)
>> Latest Java 1.8 build.
>> 
>> No matter what value I set to this attribute (true OR false OR undefined 
>> which is by default), I always see the Clients preference picked.
>> As an example, if clients order is ABCDEF, and servers order is DEFABC, no 
>> matter what value I set to this useServerCipherSuitesOrder attribute, always 
>> the order selected is ABC...
> 
> It should work when running on Java 8.
> 
> Maybe try debugging
> e.g. with breakpoint in org.apache.tomcat.util.compat.Jre8Compat
> setUseServerCipherSuitesOrder()
> 
> https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> 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: Mixed signal EMATRIX - Trademark Details Status: 710 - Cancelled - Section 8 //// 2009-05-16 CANCELLED SEC. 8 (6-YR) /// michael.bevilac...@wilmerhale.com /// KPMG case study and ROI data

[Sanjoy Bhattacharjee]

 PLM is over contact Tom cat 
On Thursday 12 October 2017, 7:43:23 PM IST, Sanjoy Bhattacharjee 
 wrote:  
 
  Honeywell Softco access the SCR time line 1. Cambridge technology 2. Philips 
R center 3. Matrix one R center 4. Geometric HCL computer 5. TCS Infosys 
Capgemini Anish IIM R 
On Thursday 12 October 2017, 7:40:23 PM IST, Sanjoy Bhattacharjee 
 wrote:  
 
  SCR sequencing W/o system managementprogram management SCR dates must tell 
the Time line Priority of the single axis time line is not important. 
---

Justia  Trademarks  DASSAULT SYSTEMES ENOVIA CORP.
DASSAULT SYSTEMES ENOVIA CORP. Trademarks
 
SYNCHRONICITY

designing network-based, and global computer network-based design management 
software applications and groupware for others…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 75118521
 
EMATRIX

computer software for product development, namely, computer software that 
enables enterprises to integrate computer applications…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 75734209
 
EMATRIX

COMPUTER EDUCATION TRAINING SERVICES; TRAINING IN THE USE OF COMPUTERS
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 75735766
 
MATRIXONE

Computer software for product development, namely, computer software that 
enables enterprises to integrate computer applications…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 75903550
 
CENTOR

computer software to access, manipulate, correlate, manage, identify and 
validate complex data, via a local, wide area or…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76063803
 
CENTOR

computer software to access, manipulate, correlate, manage, identify and 
validate complex data, via a local, wide area or…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76063804
 
X-SIGHT FOUNDATION

COMPUTER SOFTWARE THAT INTEGRATES QUERY, INDEXING, MATHEMATICAL CALCULATIONS, 
WORKFLOW AND SECURITY FEATURES FOR ENABLING…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76396332
 
MATERIALS X-SIGHT

COMPUTER SOFTWARE THAT ANALYZES MATERIALS TEST DATA FOR USE IN IDENTIFYING AND 
SELECTING NEW AND EXISTING MATERIALS TO BE…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76396336
 
COMPLIANCE X-SIGHT

COMPUTER SOFTWARE THAT AGGREGATES AND ANALYZES THE COMPLIANCE REQUIREMENTS 
PROMULGATED BY GOVERNMENT AND REGULATORY AGENCIES…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76396338
 
ISSUES X-SIGHT

COMPUTER SOFTWARE FOR USE IN COMPILING, TRACKING AND ANALYZING INFORMATION 
ASSOCIATED WITH CUSTOMER PROBLEMS, ISSUES AND…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76396339
 
TEAM CENTRAL

Computer software used for structured and unstructured team, task and meeting 
collaboration, management and access
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 76460034
 
X-SIGHT SERVER

Computer software, namely, Extensible Markup Language (XML) data management 
software used to store, query and index the…
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 78123336
 
MATRIX10

computer education training services; training in the use of computers
Owned by: DASSAULT SYSTEMES ENOVIA CORP.
Serial Number: 78236060


On Thursday 12 October 2017, 7:32:38 PM IST, Sanjoy Bhattacharjee 
 wrote:  
 
  no patent filed on e service manager 
On Thursday 12 October 2017, 7:27:43 PM IST, Sanjoy Bhattacharjee 
 wrote:  
 
 Honeywell Matrix one implementation document at Honeywell Team room KPMG case 
study and ROI dataArul Vidya Ramesh AshishVijayGiridharKarunakarSrinivas Manish 
Rajib Anirban Alan 
New Barrackpur school kept at reserve to save money for the railway bridge 
construction project in replace a underpass at goregaon railway line. All 
professor from New Barrackpur produce their Laboratory Note Book on Physics 
Chemistry Bio technology and Earth science. My vehicle number is KA05 MB 9947 
at time Matrix one sold out at United States Angshuman Majumdar Vehicle Number 
is KA 51 XX 



EMATRIX - Trademark Details



Status: 710 - Cancelled - Section 8Serial Number75734209

-cancelled
 




EMATRIX - Trademark Details
Status: 710 - Cancelled - Section 8Serial Number75734209Registration 
Number2632218Word MarkEMATRIXStatus710 - Cancelled - Section 8Status 
Date2009-05-16Filing Date1999-06-23Registration Number2632218Registration 
Date2002-10-08Mark Drawing1000 - Typeset: Word(s)/letter(s)/number(s) 
TypesetPublished for Opposition Date2001-04-10Attorney NameMichael J. 
Bevilacqua, Esq. and Barbara A. Barakat, 

Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[tomcat]

On 12.10.2017 15:33, Gali, Vamsi A wrote:

:)
IHS is IBM HTTP Server.

Thank you,


Thank you too. I feel a lot less like a dummy now.
And after reading a bit on "IHS" now, it would seem that this is at least 90% Apache httpd 
2.2, which may make it clearer to other people that maybe they could help too.





-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Thursday, October 12, 2017 9:32 AM
To: users@tomcat.apache.org
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL 
proxy connection

And for the rest of us dummies trying to follow this conversation, what might 
"IHS" be ?
Whatever Google returns doesn't seem really relevant.

On 12.10.2017 15:25, Gali, Vamsi A wrote:

Igor,
Thank you for suggesting me to turn on the ssl dubug. We are using Java 1.8 which 
by default uses TLS1.2. Looks like both IHS & Tomcat are using tls1.2 but there 
is a cipher mismatch. We have Tam directly connecting to Tomcat and the 
connectivity works w/o any SSL handshake errors. Hence, I'm suspecting IHS and will 
be trying by adding same tls1.2 ciphers that Tomcat/java supports.

Thank you,
Vamsi Gali


-Original Message-
From: Igor Cicimov [mailto:icici...@gmail.com]
Sent: Wednesday, October 11, 2017 7:33 PM
To: Tomcat Users List
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not
establish SSL proxy connection

On Thu, Oct 12, 2017 at 9:17 AM, Igor Cicimov  wrote:


On 12 Oct 2017 8:25 am, "Gali, Vamsi A"

wrote:

The debug log produced following & it's evident that handshake is
failing due to no ciphers suites in common.

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-bio--Acceptor-0, setSoTimeout(6) called Ignoring
unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1.1
http-bio--exec-2, READ: TLSv1.2 Handshake, length = 57
*** ClientHello, TLSv1.2
RandomCookie:  GMT: -2042962343 <(204)%20296-2343> bytes = { 199, 95,
13, 144, 113, 194, 145, 53, 176, 117, 165, 93, 196, 76, 17, 104, 214,
95, 96, 238, 97, 6, 240, 239, 53, 188, 180, 41 } Session ID:  {}
Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x56:0x0,
SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_RC4_128_MD5] Compression Methods:  { 0 }
***
%% Initialized:  [Session-13, SSL_NULL_WITH_NULL_NULL] %% Invalidated:
[Session-13, SSL_NULL_WITH_NULL_NULL] http-bio--exec-2, SEND
TLSv1.2 ALERT:  fatal, description = handshake_failure
http-bio--exec-2, WRITE: TLSv1.2 Alert, length = 2
http-bio--exec-2, called closeSocket()



http-bio--exec-2, handling exception: javax.net.ssl.SSLHandshakeException:
no cipher suites in common
http-bio--exec-2, IOException in getSession():
javax.net.ssl.SSLHandshakeException: no cipher suites in common


There you go, no comment needed.

Also, since you are using JSSE in your tomcat connector, you never

mentioned the Java version you are using? From the logs looks like IHS offers 
TLSv1.2 ciphers but tomcat does not support them so maybe you are running an 
outdated version of Java, maybe 1.6?

There some tools out there you can use to find the default SSL/TLS cipher suits 
that JVM will use (and I think I've seen one from Christopher Schultz). The 
tool should provide you with output like this:

$ java Ciphers
DefaultCipher
   SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   SSL_DHE_DSS_WITH_DES_CBC_SHA
   SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
   SSL_DHE_RSA_WITH_DES_CBC_SHA
   SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
   SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
   SSL_DH_anon_WITH_DES_CBC_SHA
   SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_RSA_WITH_3DES_EDE_CBC_SHA
   SSL_RSA_WITH_DES_CBC_SHA
   SSL_RSA_WITH_NULL_MD5
   SSL_RSA_WITH_NULL_SHA
*

RE: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[Gali, Vamsi A]

:)
IHS is IBM HTTP Server.

Thank you,


-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Thursday, October 12, 2017 9:32 AM
To: users@tomcat.apache.org
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL 
proxy connection

And for the rest of us dummies trying to follow this conversation, what might 
"IHS" be ?
Whatever Google returns doesn't seem really relevant.

On 12.10.2017 15:25, Gali, Vamsi A wrote:
> Igor,
> Thank you for suggesting me to turn on the ssl dubug. We are using Java 1.8 
> which by default uses TLS1.2. Looks like both IHS & Tomcat are using tls1.2 
> but there is a cipher mismatch. We have Tam directly connecting to Tomcat and 
> the connectivity works w/o any SSL handshake errors. Hence, I'm suspecting 
> IHS and will be trying by adding same tls1.2 ciphers that Tomcat/java 
> supports.
>
> Thank you,
> Vamsi Gali
>
>
> -Original Message-
> From: Igor Cicimov [mailto:icici...@gmail.com]
> Sent: Wednesday, October 11, 2017 7:33 PM
> To: Tomcat Users List
> Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not 
> establish SSL proxy connection
>
> On Thu, Oct 12, 2017 at 9:17 AM, Igor Cicimov  wrote:
>
>> On 12 Oct 2017 8:25 am, "Gali, Vamsi A"
>> 
>> wrote:
>>
>> The debug log produced following & it's evident that handshake is 
>> failing due to no ciphers suites in common.
>>
>> Allow unsafe renegotiation: false
>> Allow legacy hello messages: true
>> Is initial handshake: true
>> Is secure renegotiation: false
>> http-bio--Acceptor-0, setSoTimeout(6) called Ignoring 
>> unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> for TLSv1
>> Ignoring unsupported cipher suite:
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> for TLSv1
>> Ignoring unsupported cipher suite:
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>> for TLSv1
>> Ignoring unsupported cipher suite:
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> for TLSv1
>> Ignoring unsupported cipher suite: 
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> for TLSv1
>> Ignoring unsupported cipher suite: 
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> for TLSv1
>> Ignoring unsupported cipher suite:
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> for TLSv1.1
>> Ignoring unsupported cipher suite:
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> for TLSv1.1
>> Ignoring unsupported cipher suite:
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>> for TLSv1.1
>> Ignoring unsupported cipher suite:
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> for TLSv1.1
>> Ignoring unsupported cipher suite: 
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> for TLSv1.1
>> Ignoring unsupported cipher suite: 
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> for TLSv1.1
>> http-bio--exec-2, READ: TLSv1.2 Handshake, length = 57
>> *** ClientHello, TLSv1.2
>> RandomCookie:  GMT: -2042962343 <(204)%20296-2343> bytes = { 199, 95, 
>> 13, 144, 113, 194, 145, 53, 176, 117, 165, 93, 196, 76, 17, 104, 214, 
>> 95, 96, 238, 97, 6, 240, 239, 53, 188, 180, 41 } Session ID:  {} 
>> Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x56:0x0, 
>> SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, 
>> TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
>> SSL_RSA_WITH_RC4_128_MD5] Compression Methods:  { 0 }
>> ***
>> %% Initialized:  [Session-13, SSL_NULL_WITH_NULL_NULL] %% Invalidated:
>> [Session-13, SSL_NULL_WITH_NULL_NULL] http-bio--exec-2, SEND
>> TLSv1.2 ALERT:  fatal, description = handshake_failure 
>> http-bio--exec-2, WRITE: TLSv1.2 Alert, length = 2 
>> http-bio--exec-2, called closeSocket()
>>
>>
>>
>> http-bio--exec-2, handling exception: 
>> javax.net.ssl.SSLHandshakeException:
>> no cipher suites in common
>> http-bio--exec-2, IOException in getSession():
>> javax.net.ssl.SSLHandshakeException: no cipher suites in common
>>
>>
>> There you go, no comment needed.
>>
>> Also, since you are using JSSE in your tomcat connector, you never
> mentioned the Java version you are using? From the logs looks like IHS offers 
> TLSv1.2 ciphers but tomcat does not support them so maybe you are running an 
> outdated version of Java, maybe 1.6?
>
> There some tools out there you can use to find the default SSL/TLS cipher 
> suits that JVM will use (and I think I've seen one from Christopher Schultz). 
> The tool should provide you with output like this:
>
> $ java Ciphers
> DefaultCipher
>   SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> *SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
>   SSL_DHE_DSS_WITH_DES_CBC_SHA
>   SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> *SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>   SSL_DHE_RSA_WITH_DES_CBC_SHA
>   SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
>   SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
>   SSL_DH_anon_WITH_DES_CBC_SHA
>   SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
> *SSL_RSA_WITH_3DES_EDE_CBC_SHA
>   SSL_RSA_WITH_DES_CBC_SHA
>   SSL_RSA_WITH_NULL_MD5
>   SSL_RSA_WITH_NULL_SHA
> 

Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[tomcat]

And for the rest of us dummies trying to follow this conversation, what might 
"IHS" be ?
Whatever Google returns doesn't seem really relevant.

On 12.10.2017 15:25, Gali, Vamsi A wrote:

Igor,
Thank you for suggesting me to turn on the ssl dubug. We are using Java 1.8 which 
by default uses TLS1.2. Looks like both IHS & Tomcat are using tls1.2 but there 
is a cipher mismatch. We have Tam directly connecting to Tomcat and the 
connectivity works w/o any SSL handshake errors. Hence, I'm suspecting IHS and will 
be trying by adding same tls1.2 ciphers that Tomcat/java supports.

Thank you,
Vamsi Gali


-Original Message-
From: Igor Cicimov [mailto:icici...@gmail.com]
Sent: Wednesday, October 11, 2017 7:33 PM
To: Tomcat Users List
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL 
proxy connection

On Thu, Oct 12, 2017 at 9:17 AM, Igor Cicimov  wrote:


On 12 Oct 2017 8:25 am, "Gali, Vamsi A"

wrote:

The debug log produced following & it's evident that handshake is
failing due to no ciphers suites in common.

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-bio--Acceptor-0, setSoTimeout(6) called Ignoring
unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1.1
http-bio--exec-2, READ: TLSv1.2 Handshake, length = 57
*** ClientHello, TLSv1.2
RandomCookie:  GMT: -2042962343 <(204)%20296-2343> bytes = { 199, 95,
13, 144, 113, 194, 145, 53, 176, 117, 165, 93, 196, 76, 17, 104, 214,
95, 96, 238, 97, 6, 240, 239, 53, 188, 180, 41 } Session ID:  {}
Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x56:0x0,
SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_RC4_128_MD5] Compression Methods:  { 0 }
***
%% Initialized:  [Session-13, SSL_NULL_WITH_NULL_NULL] %% Invalidated:
[Session-13, SSL_NULL_WITH_NULL_NULL] http-bio--exec-2, SEND
TLSv1.2 ALERT:  fatal, description = handshake_failure
http-bio--exec-2, WRITE: TLSv1.2 Alert, length = 2
http-bio--exec-2, called closeSocket()



http-bio--exec-2, handling exception: javax.net.ssl.SSLHandshakeException:
no cipher suites in common
http-bio--exec-2, IOException in getSession():
javax.net.ssl.SSLHandshakeException: no cipher suites in common


There you go, no comment needed.

Also, since you are using JSSE in your tomcat connector, you never

mentioned the Java version you are using? From the logs looks like IHS offers 
TLSv1.2 ciphers but tomcat does not support them so maybe you are running an 
outdated version of Java, maybe 1.6?

There some tools out there you can use to find the default SSL/TLS cipher suits 
that JVM will use (and I think I've seen one from Christopher Schultz). The 
tool should provide you with output like this:

$ java Ciphers
DefaultCipher
  SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  SSL_DHE_DSS_WITH_DES_CBC_SHA
  SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  SSL_DHE_RSA_WITH_DES_CBC_SHA
  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
  SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
  SSL_DH_anon_WITH_DES_CBC_SHA
  SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_RSA_WITH_3DES_EDE_CBC_SHA
  SSL_RSA_WITH_DES_CBC_SHA
  SSL_RSA_WITH_NULL_MD5
  SSL_RSA_WITH_NULL_SHA
*TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  TLS_DH_anon_WITH_AES_128_CBC_SHA
  TLS_DH_anon_WITH_AES_128_CBC_SHA256
  TLS_DH_anon_WITH_AES_128_GCM_SHA256
...

then pick up one of the supported default ciphers (marked with star) and use it 
in IHS (as it is or translated in IHS way, no idea about that) so you get a 
match. I know nothing about IHS so can't help there.

If that doesn't work 

RE: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[Gali, Vamsi A]

Igor,
Thank you for suggesting me to turn on the ssl dubug. We are using Java 1.8 
which by default uses TLS1.2. Looks like both IHS & Tomcat are using tls1.2 but 
there is a cipher mismatch. We have Tam directly connecting to Tomcat and the 
connectivity works w/o any SSL handshake errors. Hence, I'm suspecting IHS and 
will be trying by adding same tls1.2 ciphers that Tomcat/java supports.

Thank you,
Vamsi Gali


-Original Message-
From: Igor Cicimov [mailto:icici...@gmail.com] 
Sent: Wednesday, October 11, 2017 7:33 PM
To: Tomcat Users List
Subject: Re: FW: [error] SSL0266E: Handshake Failed, Could not establish SSL 
proxy connection

On Thu, Oct 12, 2017 at 9:17 AM, Igor Cicimov  wrote:

> On 12 Oct 2017 8:25 am, "Gali, Vamsi A" 
> 
> wrote:
>
> The debug log produced following & it's evident that handshake is 
> failing due to no ciphers suites in common.
>
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> http-bio--Acceptor-0, setSoTimeout(6) called Ignoring 
> unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: 
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: 
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> for TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> for TLSv1
> Ignoring unsupported cipher suite: 
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: 
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: 
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> for TLSv1.1
> http-bio--exec-2, READ: TLSv1.2 Handshake, length = 57
> *** ClientHello, TLSv1.2
> RandomCookie:  GMT: -2042962343 <(204)%20296-2343> bytes = { 199, 95, 
> 13, 144, 113, 194, 145, 53, 176, 117, 165, 93, 196, 76, 17, 104, 214, 
> 95, 96, 238, 97, 6, 240, 239, 53, 188, 180, 41 } Session ID:  {} 
> Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x56:0x0, 
> SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
> SSL_RSA_WITH_RC4_128_MD5] Compression Methods:  { 0 }
> ***
> %% Initialized:  [Session-13, SSL_NULL_WITH_NULL_NULL] %% Invalidated:  
> [Session-13, SSL_NULL_WITH_NULL_NULL] http-bio--exec-2, SEND 
> TLSv1.2 ALERT:  fatal, description = handshake_failure 
> http-bio--exec-2, WRITE: TLSv1.2 Alert, length = 2 
> http-bio--exec-2, called closeSocket()
>
>
>
> http-bio--exec-2, handling exception: javax.net.ssl.SSLHandshakeException:
> no cipher suites in common
> http-bio--exec-2, IOException in getSession():
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
>
>
> There you go, no comment needed.
>
> Also, since you are using JSSE in your tomcat connector, you never
mentioned the Java version you are using? From the logs looks like IHS offers 
TLSv1.2 ciphers but tomcat does not support them so maybe you are running an 
outdated version of Java, maybe 1.6?

There some tools out there you can use to find the default SSL/TLS cipher suits 
that JVM will use (and I think I've seen one from Christopher Schultz). The 
tool should provide you with output like this:

$ java Ciphers
DefaultCipher
 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 SSL_DHE_DSS_WITH_DES_CBC_SHA
 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
 SSL_DHE_RSA_WITH_DES_CBC_SHA
 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
 SSL_DH_anon_WITH_DES_CBC_SHA
 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
*SSL_RSA_WITH_3DES_EDE_CBC_SHA
 SSL_RSA_WITH_DES_CBC_SHA
 SSL_RSA_WITH_NULL_MD5
 SSL_RSA_WITH_NULL_SHA
*TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_DH_anon_WITH_AES_128_CBC_SHA
 TLS_DH_anon_WITH_AES_128_CBC_SHA256
 TLS_DH_anon_WITH_AES_128_GCM_SHA256
...

then pick up one of the supported default ciphers (marked with star) and use it 
in IHS (as it is or translated in IHS way, no idea about that) so you get a 
match. I know nothing about IHS so can't help there.

If that doesn't work then I would say IHS does some funky stuff with the