Re: setenv.sh tomcat8 changelog
Hello Christoph, Il giorno lun, 04/12/2023 alle 16.10 +0100, Christoph Kukulies ha scritto: [...] > Where do I find "setenv.sh" in my tomcat9 (Ubuntu) distribution? I think all Debian derivatives use /etc/default/tomcat8 file for setting those variables. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sharing catalina home among tomcat machines in a load balanced environment gives problems with log files
Hello, Il giorno mar, 10/10/2023 alle 06.59 -0400, Christopher Schultz ha scritto: > Mark, > > On 10/10/23 06:38, Mark Thomas wrote: > > Running multiple instances of Tomcat from the same CATALINA_BASE is > > totally unsupported. This isn't one of those "We don't technically > > support that but you should be OK situations". This is one of the rare > > "You do that and it *will* break and you will be on your own when it > > does." situations. > > +1 > > Both the logs/ and the work/ directories will overwrite each other, > probably to the point of not only corruption (e.g. log files) but also > instability -- because of the work/ directory. Files will appear and > disappear surprisingly to one or the other running Tomcat and you WILL > have errors, etc. Thank you very much to all. I am going to use two CATALINA_BASE and I'll try to change the pipeline we use for deploy. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sharing catalina home among tomcat machines in a load balanced environment gives problems with log files
Hello Peter, Il giorno mar, 10/10/2023 alle 11.21 +0200, l...@kreuser.name ha scritto: > Guiseppe, > > did you consider the separation of CATALINA_HOME and CATALINA_BASE. Look > at the RUNNING.txt file that describes the purpose... > > Plus some symbolic links that have the really common files linked to the > BASE directory? I did not use different CATALINA_BASE and CATALINA_HOME since this would have required to deploy all applications on two different tomcats and my pipeline only allows to deploy to one tomcat putting an XML file in $CATALINA_BASE/conf/Catalina/localhost directory. Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Sharing catalina home among tomcat machines in a load balanced environment gives problems with log files
Hello, I am testing an environment with a load balancer and two machines that host tomcat. The two machines should really be identical, and no tomcat cluster is configured (no sessions are shared between the tomcats). I would like to put the tomcat installation (catalina_home) in a shared directory and have both tomcat use it. In a test installation I only have some problems with log files, since they are shared and the tomcats write concurrently to the same files, overlapping their text. I set the property java.util.logging.config.file to a per tomcat properties file, and this works for some of the files, but not for all. In fact, at least the AccessLogValve does not have any way to specify a different directory for each host, i.e., adding the hostname in the path. So, these are my questions: is this way of sharing tomcat_home a viable solution? Are there any way to store all log files in separate directories based on the hostname or the ip address or a java parameter (using -D... on the command line)? Is there a way to change log locking/buffering in a way that written text does not overlap when two tomcats write concurrently? Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk and application deployed check
Il giorno ven, 29/05/2020 alle 14.09 -0400, Christopher Schultz ha scritto: > Giuseppe, > > On 5/29/20 11:57, Giuseppe Sacco wrote: > > [...] > > misconfigured machines and failed with 404 errors. From what I > > understood, the mod_jk protocol only allows to check it tomcat is > > alive. Is it possibile to also check if an application is deployed > > (giving a dedicated URL in the application context)? Thank > > you,Giuseppe > > One way to do this would be to create a ROOT context which returns > something other than 404 for all requests. Maybe return 500 status > for > example. > > If /myapp/ isn't deployed, the ROOT web application will respond with > 500 and mod_jk will mark the node as degraded. Thank you Cris, I am going to try this solution. Bye, Giuseppe signature.asc Description: This is a digitally signed message part
mod_jk and application deployed check
Hello,I have an apache httpd with mod_jk that load balance requests among two different tomcat servers.Today, one of the tomcat servers has been rebooted and tomcat could not deploy the application since it failed to find a configuration file. Please note that tomcat was running correctly, only the application deploy failed. The balancer could not understand that one of the servers was not to be used: half of the requests were going to the misconfigured machines and failed with 404 errors. >From what I understood, the mod_jk protocol only allows to check it tomcat is alive. Is it possibile to also check if an application is deployed (giving a dedicated URL in the application context)? Thank you,Giuseppe
Re: Connector difference explanation request - two ways of getting SSL in server.xml
Hello Richard, Il giorno sab, 22/06/2019 alle 21.19 +, Richard Huntrods ha scritto: > Apologies if this is really basic, but I've seen two ways of handling > https (SSL) for tomcat and don't understand the differences. [...] > protocol="org.apache.coyote.http11.Http11NioProtocol" > maxThreads="150" SSLEnabled="true"> > > certificateFile="/etc/letsencrypt/live/mydomain.com/cert.pem" > certificateKeyFile="/etc/letsencrypt/live/mydomain.com/privkey.pem" > certificateChainFile="/etc/letsencrypt/live/mydomain.com/chain.pem" > /> > > > > vs. > > maxThreads="150" enableLookups="false" scheme="https" > secure="true" >keystoreFile="./keys/.keystore" keystorePass="mypass" >clientAuth="false" sslProtocol="TLS" /> If I understand correctly, prior to 8.5, there were two different syntaxes: one for SSL implemented by JSSE and one for openssl. The new syntax allow to specify all parameters in one way that both implementations recognize. Moreover, you may have configurations previously not possibile, i.e., you may now have many certificates (one RSA, one EC, one DSS) on the same connector: the right certificate will be picked up dynamically based on the SSL cipher used. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: response sent before request
Hello Mark, Il giorno gio, 07/02/2019 alle 09.49 +, Mark Thomas ha scritto: > On 06/02/2019 17:27, Giuseppe Sacco wrote: [...] > > So, I wonder, what instructs tomcat to start parsing a request? Is > > it > > the newline inbetween the header and the body? How is it possible > > to > > explain this behaviour? > > A 500 response will result in the connection being closed. > > It sounds like something in an application is holding on to a > reference > to the request and/or the response for longer than it should. These > objects are recycled and re-used so retaining references to them will > cause problems. One of the first things to try is: > > -Dorg.apache.catalina.connector.RECYCLE_FACADES=true > > See > https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Secu > rity A few hours ago, we updated tomcat from 8.5.20 to 8.5.37 and it seems the problem is no more present. We will try it on a live environment in a few hours. Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
response sent before request
Hello, I have a tomcat 8.5.20 installation that handle many applications. When calling one of the URLs of a specific application, sometimes I get a 500 http error. Please note that this it does not happens always. The connector uses SSL, so I setup wireshark and decrypted the traffic. Finally I found this: an SSL stream that displays the response before the request, i.e., this is what is shown as decrypted: *** HTTP/1.1 500 Content-Type: text/plain Content-Length: 57 Date: Wed, 06 Feb 2019 15:23:46 GMT Connection: close The call failed on the server; see server log for detailsPOST /lnuiprod/gwtui/persist HTTP/1.1 Host: srclnprod.mydomain.tld:8445 Connection: keep-alive Content-Length: 18118 X-GWT-Module-Base: https://srclnprod.mydomain.tld:8445/lnuiprod/gwtui X-GWT-Permutation: 8E921 Origin: https://srclnprod.mydomain.tld:8445 User-Agent: Mozilla/.36 Content-Type: text/x-gwt-rpc; charset=UTF-8 Accept: */* Referer: https://srclnprod.mydomain.tld:8445/lnui/servlet/login Accept-Encoding: gzip, deflate, br Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: JSESSIONID=B.2F£ 7|1|14|http... (body continues until the end of the stream) *** I see the request in the valve log. I see an exception in the tomcat log from a servlet that complains about an unparseable request. The servlet that logs the message is not the one associated to the URL. I am not even sure it is from the same context. So, I wonder, what instructs tomcat to start parsing a request? Is it the newline inbetween the header and the body? How is it possible to explain this behaviour? Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Cris,
Il giorno ven, 15/02/2013 alle 12.36 -0500, Christopher Schultz ha
scritto:
[...]
Allow legacy hello messages: true [snip] http-192.168.1.55-8443-1,
READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3
RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77,
52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47,
219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites:
[TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown
0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b,
SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods:
{ 0 } ***
So the client is doing an SSLv3 handshake. The message above about
allowing legacy hellos seems like it should support a SSLv3
handshake. Looking at the ciphers, your JVM (without BouncyCastle) and
client truly have no overlap. I'm actually surprised that your JVM
does not support any TLS_RSA_* or TLS_DHE_* ciphers. Can you re-run my
cipher-dump program without BouncyCastle and provide the full output?
I was a little unclear as to what you posted last time.
I listed all providers here:
http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html
as you may see, a few of them are TLS_RSA and TLS_DHE:
* TLS_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA
They are also listed as default ciphers, so -- if I understood what
default means -- they should not be enabled explicitly.
They overlap with those client ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Is there any possibility that some of those server ciphers are disabled
because of the algorithm used in the server certificate? Its signature
algorithm is SHA1withDSA. I created it with this command line:
keytool -genkeypair -alias tomcat -keystore ~tomcat6/.keystore
A side note: is it possibile to put tomcat behind a web server and make
the latter encrypt in SSL? This would imply that communication between
the web server and tomcat would be in clear, but how do I create the
connector proxy* information? I may specify proxyName and proxyPort, but
I cannot specify proxyProtocol. Is this right?
Bye,
Giuseppe
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Martin, Il giorno ven, 15/02/2013 alle 18.29 -0500, Martin Gainty ha scritto: someone put cipherSuites patch on TC 7 Connector.. *IF you are implementing TC7 Connector with cipherSuites attribute support and have not specified cipherSuites supported by your ppk keys* then yes its tomcats fault I am using 6.0.36. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Il giorno gio, 14/02/2013 alle 11.38 -0500, Christopher Schultz ha scritto: [...] Tomcat version is the one shipped with Debian, and uses jdk 1.6.0_u39 with jce unrestricted policy. I also added bouncy castle jar in $JAVA_HOME/jre/lib/ext and added its provider in $JAVA_HOME/jre/lib/security/java.security as last in the provider list. After restarting tomcat nothing changed. Did you add Bouncy Castle just to see if it would improve things? Or are you attempting to use Bouncy Castle as your provider? I added it in oder to add moe ciphes. I don't even know if this new povider is used at all. The only step I did are the one listed above. [...] Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS proxyName=www.my-visible-name.tld proxyPort=8443 address=192.168.1.55 / It's traditional to specify a server key and certificate when configuring SSL. Where are yours configured? I used default values: the keystore in named .keystore and is in the home directory of the user running tomcat. It contains only one key pair and one certificate, and its password is the standard one. So, my question: how to configure tomcat for accepting a broader range of ciphers, or at least to accept even one of those used by this browser? The default cipher suite depends upon your JVM, and is usually fairly inclusive. Here's a little program I wrote to find out what your JVM will support and what its default cipher suite will be: http://markmail.org/message/zn4namfhypyxum23 Right. This is why I added bouncycastle. Anyway, I just tried the program in the link you supplied. This is its output: /tmp# java -showversion SSLInfo java version 1.6.0_39 Java(TM) SE Runtime Environment (build 1.6.0_39-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode) Default Cipher * 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_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 * SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * SSL_RSA_EXPORT_WITH_RC4_40_MD5 * SSL_RSA_WITH_3DES_EDE_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA * SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * TLS_DHE_DSS_WITH_AES_256_CBC_SHA * TLS_DHE_RSA_WITH_AES_128_CBC_SHA * TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA * TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA * TLS_ECDHE_ECDSA_WITH_RC4_128_SHA * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA * TLS_ECDHE_RSA_WITH_RC4_128_SHA * TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA * TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_NULL_SHA * TLS_ECDH_ECDSA_WITH_RC4_128_SHA * TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA * TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_NULL_SHA * TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA * TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_RC4_128_SHA * TLS_RSA_WITH_AES_128_CBC_SHA * TLS_RSA_WITH_AES_256_CBC_SHA If I run it after removing the bouncy castle provider, this list become short. The diff is about ciphers that iPad does not use, so I think I may remove bouncy castle at all: * TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA * TLS_ECDHE_ECDSA_WITH_RC4_128_SHA * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA * TLS_ECDHE_RSA_WITH_RC4_128_SHA
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Il giorno ven, 15/02/2013 alle 09.39 +0100, Giuseppe Sacco ha scritto: [...] Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS proxyName=www.my-visible-name.tld proxyPort=8443 address=192.168.1.55 / It's traditional to specify a server key and certificate when configuring SSL. Where are yours configured? I used default values: the keystore in named .keystore and is in the home directory of the user running tomcat. It contains only one key pair and one certificate, and its password is the standard one. A complete log from ssldump when connecting with safari on iPad is here (http://centrum.lixper.it/~giuseppe/ipad-ssl-problem-with-tomcat.html). I start thinking this is not a problem of cipher, but of protocol version. In fact, I checked the complete list of available ciphers (http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphes.html) and there are a few matching. Should I try changing the `sslProtocol` from `TLS` so some `SSLv?`. Thanks, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Debugging the SSL handshake, I found that the problem is really about
ciphers because the handshake fails with exception
javax.net.ssl.SSLHandshakeException: no cipher suites in common
So, this is really something to be investigated in JSSE instead of
tomcat. I am sorry for noise in this list :-(
This is the complete log obtained with -Djavax.net.debug=all:
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-192.168.1.55-8443-1, setSoTimeout(6) called
[Raw read]: length = 5
: 16 03 00 00 4B K
[Raw read]: length = 75
: 01 00 00 47 03 00 51 1E 33 5C CB 56 A8 58 4B 4D ...G..Q.3\.V.XKM
0010: 34 86 04 4C CC 4E 00 A0 A8 7B 60 4E 6A 17 28 2F 4..L.N`Nj.(/
0020: DB 51 1C 17 AE 9C 00 00 20 00 FF 00 3D 00 3C 00 .Q.. ...=..
0030: 2F 00 05 00 04 00 35 00 0A 00 67 00 6B 00 33 00 /.5...g.k.3.
0040: 39 00 16 00 3B 00 02 00 01 01 00 9...;..
http-192.168.1.55-8443-1, READ: SSLv3 Handshake, length = 75
*** ClientHello, SSLv3
RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, 52, 134, 4,
76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, 219, 81, 28, 23, 174,
156 }
Session ID: {}
Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown
0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, SSL_RSA_WITH_NULL_SHA,
SSL_RSA_WITH_NULL_MD5]
Compression Methods: { 0 }
***
[read] MD5 and SHA1 hashes: len = 75
: 01 00 00 47 03 00 51 1E 33 5C CB 56 A8 58 4B 4D ...G..Q.3\.V.XKM
0010: 34 86 04 4C CC 4E 00 A0 A8 7B 60 4E 6A 17 28 2F 4..L.N`Nj.(/
0020: DB 51 1C 17 AE 9C 00 00 20 00 FF 00 3D 00 3C 00 .Q.. ...=..
0030: 2F 00 05 00 04 00 35 00 0A 00 67 00 6B 00 33 00 /.5...g.k.3.
0040: 39 00 16 00 3B 00 02 00 01 01 00 9...;..
http-192.168.1.55-8443-1, SEND SSLv3 ALERT: fatal, description =
handshake_failure
http-192.168.1.55-8443-1, WRITE: SSLv3 Alert, length = 2
[Raw write]: length = 7
: 15 03 00 00 02 02 28 ..(
http-192.168.1.55-8443-1, called closeSocket()
http-192.168.1.55-8443-1, handling exception:
javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-192.168.1.55-8443-1, called close()
http-192.168.1.55-8443-1, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi all, I have an application deployed on tomcat 6.0.35 and linux/amd64 with a JSSE https connector. When I try to connect to this site with default iPad browser, I always get an error message about the connection cannot be established. Tomcat version is the one shipped with Debian, and uses jdk 1.6.0_u39 with jce unrestricted policy. I also added bouncy castle jar in $JAVA_HOME/jre/lib/ext and added its provider in $JAVA_HOME/jre/lib/security/java.security as last in the provider list. After restarting tomcat nothing changed. I used the command line tool ssldump to check what happens and it seems the problem is in the cipher suite used by iPad: none of the ciphers is accepted by the server. This is what ssldump command show: New TCP connection #1: host35-105-static.24-87-b.business.telecomitalia.it(59049) - 192.168.1.55(8443) 1 1 0.0979 (0.0979) CS Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods NULL iPad does try a few times, changing the version number, but it fails every time and eventually stop. When connecting using Chrome on the very same iPad, the connection works. The relevant dump is: New TCP connection #1: host35-105-static.24-87-b.business.telecomitalia.it(59049) - 192.168.1.55(8443) 1 1 0.0979 (0.0979) CS Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods NULL Ths cipher accepted by the server is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA The connector I use is: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS proxyName=www.my-visible-name.tld proxyPort=8443 address=192.168.1.55 / This is a JSSE connector since it display this message in log file: 13-feb-2013 12.57.49 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-192.168.1.55-8443 So, my question: how to configure tomcat for accepting a broader range of ciphers, or at least to accept even one of those used by this browser? Thank you very much, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
