Re: Tomcat 7.0.34 and ecj 3.7.2/4.2.1
2013/1/11 Ralph Schaer ralphsch...@gmail.com: Hi Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file of tomcat-embed-jasper still points to version 3.7.2 of ecj. Is it safe to use ecj 3.7.2 with Tomcat 7.0.34? It's unfortunately not possible to override this, because I haven't found the 4.2.1 artifact in the central repository. 1. Thank you for reporting the issue. I fixed this in svn, but 7.0.35 has already been tagged several hours ago. 2. Absence of ecj 4.2.1 in central repository is not a stopper. It happened before and is expected to happen in the future. You can install it locally. http://markmail.org/message/xyw3bv2flmbhsdt4 https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 3. I personally would recommend to go with 4.2.1. It is known that Eclipse 3.7.2 fails to compile the current Tomcat trunk sources (the compiler crashes), 4.2.1 works fine. There was report by Jess Holle on a crash with 4.2.1, but what causes the crash is unknown and I have not observed anything like that. http://tomcat.markmail.org/thread/oe5wwu3dm2zcjp4m Anyway, if you are in doubt, you may try to run precompilation for your JSPs with JspC just to make sure that everything compiles nicely. (I do not suggest to actually use the compiled classes. I mean just to run a compilation to check that they are compilable). 4. The bump of ecj version included a change in one of java classes. @Override is a compile-time annotation. You should still be able to run with 3.7.2. http://svn.apache.org/viewvc?view=revisionrevision=1411587 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat vs IIS download speed - configuration suggestions?
On 10 Jan 2013, at 20:20, Daniel Mikusa dmik...@vmware.com wrote: On Jan 10, 2013, at 3:10 PM, Linoma DevTeam wrote: Thank you everyone for the responses/suggestions. I did ensure that those were the same during the tests, but had removed that from the server.xml before sending. Both servers had negotiated the equivalent of TLS_RSA_WITH_AES_128_CBC_SHA with the client during testing. Also, i've verified the JVM is in server mode, and I'm currently using 1.6.0_14. This is pretty old, you might also try the latest 1.6.0_x release and/or the latest 17.0_x release. Those could have some performance improvements which would narrow the gap. +1 Don't underestimate the impact of that. p Dan At times i can hit increased speeds of 10.8MB/s for IIS (about as fast as this server's network card can handle), with tomcat running close to 7.8 MB/s. (I'm just thinking out loud here) Assuming this is a normal difference with tomcat running at 72% the speed of IIS, and if the system was congested to the point of slowing down the downloads from the servers, then I would expect tomcat to run at 2.5 MB/s if IIS was serving files at 3.5 MB/s. It however looks like tomcat is serving data at a consistent 3.0 MB/s slower than IIS (not percentage based), which is why i saw 350 KB/s against the 3.5 MB/s from IIS? Anyway, I will try the APR connector and let you know. Thanks again for your comments! On Thu, Jan 10, 2013 at 8:31 AM, David kerber dcker...@verizon.net wrote: On 1/10/2013 8:56 AM, Linoma DevTeam wrote: Hi everyone, I'm running some comparison tests with tomcat 6.0.35 and IIS running in parallel on Windows Server 2008 R2. Now I would expect Tomcat to be somewhat slower, given the extra JVM layer, but in some situations, i'm seeing differences that are tough to swallow. What JVM are you running under? Is it running the client or server version? I've found huge performance improvements in some kind of operations under a server JVM compared to client ones. D Downloads IIS ~3.7 MB/s Tomcat ~350 KB/s Test Details: I placed a ~500MB file in the document root of the web app on tomcat and set up an HTTPS connector. Then I set up IIS with the same file and an HTTPS listener. I configured the cipher suite in tomcat to be the same one that was negotiated between IIS and my Chrome browser. Finally, I set the JVM max memory to 1024MB with a min of 900MB to reduce the impact of the GC and the memory allocation. I'm using HTTP/1.1 connectors with pretty standard configuration: Server port=9005 shutdown=SHUTDOWN Service name=admin Connector port=9080 / Connector port=9443 protocol=HTTP/1.1 SSLEnabled=true enableLookups=false disableUploadTimeout=true scheme=https secure=true clientAuth=false sslProtocol=TLS algorithm=SunX509 keystoreFile=C:\temp\sample_**keystore.jks keystorePass=password keyAlias=sample-key keystoreType=JKS truststoreFile=C:\temp\**sample_truststore.jks truststorePass=password truststoreType=JKS / Engine name=admin defaultHost=localhost Host name=localhost appBase=webapps errorReportValveClass=com.**company.**CustomErrorReportValve Context path=/sample docBase=C:\temp\application\**WebRoot reloadable=false Loader delegate=true / /Context /Host /Engine /Service /Server So, I extend the question of, why would tomcat only be able to reach 10% of the speed IIS is able to server when running parallel tests? Any suggestions on configurations that I could adjust on Tomcat, the JVM, or operating system that improve that download speed? Thanks in advance! --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Change port that apache runs on in tomcat/apache setup
Hello: I am trying to get mod_jk to work, and it works if tomcat is listening on port 8080, but I try to shut down port 8080 from tomcat and configure it in an Apache vhost, but apache dies. I think I am following the rules, but obviously I am missing something fundamental. Would appreciate help. First I go into server.xml and comment out the following: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / The idea is that I want to use AJP instead of HTTP in Tomcat. Then I create an Apache VirtualHost with the following: VirtualHost *:8080 ServerName tomcat.sample.com DocumentRoot /var/www/httpd/vhosts/tomcat.sample.com IfModule mod_jk.c JkMount /sample sample1 JkMount /sample/* sample1 IfModule /VirtualHost I created a workers.properties which looks like this: worker.list=sample1 worker.sample1.port=8009 worker.sample1.host=localhost worker.sample1.type=ajp13 As I understand it, Apache should now show up in netstat listening on port 8080, but it doesn't. I see java listening on port 8009 as expected. Can you see what I am missing? Just want to be able to change the port that my tomcat is access by. Appreciate any help, CaptainVic - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/10/13 10:35 PM, Martin Gainty wrote: its a simple question what does ciphers parameter in Connector have anything to do with the supported ciphers from the key itself the 2 are disconnected Supported ciphers may be set in the connector without regard to any details of the server's X509 key or the certificate created with it. You can have an RSA key and still support RC4-SHA as one of your ciphers. Likewise, you can use a DSA key (for which OpenSSL always uses MD5 as the signature algorithm) with ciphers that use SHA1 as the signature algorithm. Keys/certs and ciphers are entirely orthogonal in the algorithms they support. SSL uses asymmetric encryption to exchange symmetric cipher keys using any cipher upon which the server and client can agree. Those ciphers are not limited by anything in the server's certificate or key. please dont waste my time and anyone elses with insults when you are unable to answer this simple question I have answered it above. If you disagree with my answer, please be specific. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwNQYACgkQ9CaO5/Lv0PATEQCgo3LI5SbHiChoPJRgT1kKHDAO ZyMAoJdz9eMl8xRXhvDEfIOfOITTbLHi =f/P3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/10/13 11:00 PM, Martin Gainty wrote: http://security.stackexchange.com/questions/7440/what-ciphers-should-i-use-in-my-web-server-after-i-configure-my-ssl-certificate With a RSA key you can nominally use the RSA and DHE_RSA cipher suite. But if the server certificate has a Key Usage extension which does not include the keyEncipherment flag, then you are nominally limited to DHE_RSA. With a DSA key you can use only a DHE_DSS cipher suite. With a Diffie-Hellman key, you can use only one of DH_RSA or DH_DSS, depending on the issuing certificate authority key type. your witness My certificate technical details: Signature Algorithm: sha1WithRSAEncryption Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) $ sslscan [myhost] | grep Accepted Accepted SSLv3 256 bits DHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 128 bits DHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 So, my server with a 2048-bit RSA key with SHA1 signature will accept all kinds of key exchange schemes (DHE, EDH, etc.), all kinds of block ciphers (AES, DES, 3DES, RC4), and all kinds of MAC algorithms (SHA1, MD5). Your assertion that somehow I'm limited to RSA + SHA1 + some weird selection of ciphers that are bound to my key or certificate's technical details is simply false. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwONUACgkQ9CaO5/Lv0PAZhQCgiwg9ooMWXN8rmu9dCvbyyFrF SEAAn1GXVnWi37S13DXUY7HNMntBvuYl =8whg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change port that apache runs on in tomcat/apache setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vic, On 1/11/13 9:53 AM, vi...@thepenguin.org wrote: I am trying to get mod_jk to work, and it works if tomcat is listening on port 8080, but I try to shut down port 8080 from tomcat and configure it in an Apache vhost, but apache dies. I think I am following the rules, but obviously I am missing something fundamental. Would appreciate help. First I go into server.xml and comment out the following: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / The idea is that I want to use AJP instead of HTTP in Tomcat. Ok. Then I create an Apache VirtualHost with the following: VirtualHost *:8080 ServerName tomcat.sample.com DocumentRoot /var/www/httpd/vhosts/tomcat.sample.com IfModule mod_jk.c JkMount /sample sample1 JkMount /sample/* sample1 IfModule /VirtualHost I created a workers.properties which looks like this: worker.list=sample1 worker.sample1.port=8009 worker.sample1.host=localhost worker.sample1.type=ajp13 That looks good so far. As I understand it, Apache should now show up in netstat listening on port 8080, but it doesn't. I see java listening on port 8009 as expected. Can you see what I am missing? Just want to be able to change the port that my tomcat is access by. Is anything listening on 8080? What does the Apache error log show? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwOcoACgkQ9CaO5/Lv0PAw9QCgoOHRx/BF9XBaSrnHWLtRh35J X1YAnRn09zmxdtf0/nt7YU2OPqM0N0en =obqO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat AutoDeploy Interval (Delay / Frequency)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radek, On 1/10/13 6:28 AM, Radek Szamrej wrote: Thank you for the great tip, with your help I was able to find it (and confirmed it works): To summarize: Setting for the Host in sever.xml is called backgroundProcessorDelay (value expressed in seconds) In server.xml: Host appBase=webapps autoDeploy=true ... backgroundProcessorDelay=1 It makes Tomcat to auto-redeploy using 1s interval. Problem solved. Come on back when you find that your WAR file takes more than 1/2 second to scp/copy into place and you get broken deployments. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwPDMACgkQ9CaO5/Lv0PAf5wCdEWIy3u8bbKjS9m6F63wyMZmA yuAAoIEWAF0vO6lcF2+7z82RHq+bPFjq =i+5u -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change port that apache runs on in tomcat/apache setup
Nothing is listening on port 8080 now. That is what confused me. It should be, right? -Original Message- From: Christopher Schultz ch...@christopherschultz.net Sent: Friday, January 11, 2013 11:11am To: Tomcat Users List users@tomcat.apache.org Subject: Re: Change port that apache runs on in tomcat/apache setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vic, On 1/11/13 9:53 AM, vi...@thepenguin.org wrote: I am trying to get mod_jk to work, and it works if tomcat is listening on port 8080, but I try to shut down port 8080 from tomcat and configure it in an Apache vhost, but apache dies. I think I am following the rules, but obviously I am missing something fundamental. Would appreciate help. First I go into server.xml and comment out the following: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / The idea is that I want to use AJP instead of HTTP in Tomcat. Ok. Then I create an Apache VirtualHost with the following: VirtualHost *:8080 ServerName tomcat.sample.com DocumentRoot /var/www/httpd/vhosts/tomcat.sample.com IfModule mod_jk.c JkMount /sample sample1 JkMount /sample/* sample1 IfModule /VirtualHost I created a workers.properties which looks like this: worker.list=sample1 worker.sample1.port=8009 worker.sample1.host=localhost worker.sample1.type=ajp13 That looks good so far. As I understand it, Apache should now show up in netstat listening on port 8080, but it doesn't. I see java listening on port 8009 as expected. Can you see what I am missing? Just want to be able to change the port that my tomcat is access by. Is anything listening on 8080? What does the Apache error log show? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwOcoACgkQ9CaO5/Lv0PAw9QCgoOHRx/BF9XBaSrnHWLtRh35J X1YAnRn09zmxdtf0/nt7YU2OPqM0N0en =obqO -END PGP SIGNATURE- - 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: Change port that apache runs on in tomcat/apache setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vic, On 1/11/13 11:48 AM, vi...@thepenguin.org wrote: Nothing is listening on port 8080 now. That is what confused me. It should be, right? Did you actually configure Apache httpd to listen on port 8080? Simply doing VirtualHost *:8080 doesn't actually listen on that port: it configured a virtual host that will respond to requests that come in on that port. You have to use the Listen directive to actually start listening. Some Linux distros use a file called ports.conf that just contains Listen directives, so you may never have seen that directive. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwRFsACgkQ9CaO5/Lv0PD93QCdHWrAPJ5lPoALD5QsuhurtePW l4sAn3mSxCf93qPkqw8/URGhxH507B+h =JIfN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change port that apache runs on in tomcat/apache setup
Thanks the problem was that the changes I was making in ports.conf were not being included in the apache config. I added an include in httpd.conf and now it works. Such a silly thing to miss. Thanks, CaptainVic -Original Message- From: Christopher Schultz ch...@christopherschultz.net Sent: Friday, January 11, 2013 11:56am To: Tomcat Users List users@tomcat.apache.org Subject: Re: Change port that apache runs on in tomcat/apache setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vic, On 1/11/13 11:48 AM, vi...@thepenguin.org wrote: Nothing is listening on port 8080 now. That is what confused me. It should be, right? Did you actually configure Apache httpd to listen on port 8080? Simply doing VirtualHost *:8080 doesn't actually listen on that port: it configured a virtual host that will respond to requests that come in on that port. You have to use the Listen directive to actually start listening. Some Linux distros use a file called ports.conf that just contains Listen directives, so you may never have seen that directive. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDwRFsACgkQ9CaO5/Lv0PD93QCdHWrAPJ5lPoALD5QsuhurtePW l4sAn3mSxCf93qPkqw8/URGhxH507B+h =JIfN -END PGP SIGNATURE- - 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: docBase
-Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: docBase Tomcat 7.0.34 Java 1.6.0_35 Can the document base of a context be an administrative share? Ex: \\servername\share$\somedirectoryfile:///\\servername\share$\somedire ctory I run tomcat as a service using a local account on webserver1, that same local account has read access to the administrative share (checked the passwords to make sure they were the same), but I'm getting an illegalArgumentException in the logs. The local account has share access and permissions on the \\servername\share$ root directory. Leo Never mind. It always takes a post to find the error right after I hit send. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: docBase
On 1/11/2013 3:24 PM, Leo Donahue - RDSA IT wrote: Tomcat 7.0.34 Java 1.6.0_35 Can the document base of a context be an administrative share? Ex: \\servername\share$\somedirectoryfile:///\\servername\share$\somedirectory I run tomcat as a service using a local account on webserver1, that same local account has read access to the administrative share (checked the passwords to make sure they were the same), but I'm getting an illegalArgumentException in the logs. The local account has share access and permissions on the \\servername\share$ root directory. I assume you mean a user that you have set up, and not the local system account? I believe (not sure) that to access the administrative share, the user has to have admin privileges on the machine hosting the share you want to access. SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base \\servername\share$\somedirectory does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:138) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4906) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5086) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Leo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: docBase
On 1/11/2013 3:28 PM, Leo Donahue - RDSA IT wrote: -Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: docBase Tomcat 7.0.34 Java 1.6.0_35 Can the document base of a context be an administrative share? Ex: \\servername\share$\somedirectoryfile:///\\servername\share$\somedire ctory I run tomcat as a service using a local account on webserver1, that same local account has read access to the administrative share (checked the passwords to make sure they were the same), but I'm getting an illegalArgumentException in the logs. The local account has share access and permissions on the \\servername\share$ root directory. Leo Never mind. It always takes a post to find the error right after I hit send. Care to share your findings? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: docBase
-Original Message- From: David kerber [mailto:dcker...@verizon.net] Subject: Re: docBase On 1/11/2013 3:28 PM, Leo Donahue - RDSA IT wrote: -Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: docBase Tomcat 7.0.34 Java 1.6.0_35 Can the document base of a context be an administrative share? Ex: \\servername\share$\somedirectoryfile:///\\servername\share$\somedir e ctory I run tomcat as a service using a local account on webserver1, that same local account has read access to the administrative share (checked the passwords to make sure they were the same), but I'm getting an illegalArgumentException in the logs. The local account has share access and permissions on the \\servername\share$ root directory. Leo Never mind. It always takes a post to find the error right after I hit send. Care to share your findings? I take it all back. The typo in my context file I thought was the problem, was not it. In Tomcat 7.0.34 I had a context file in conf/Catalina/localhost called output.xml The docBase attribute was: docBase=\\servername\share$\gisoutput The purpose was to create a virtual output directory on Tomcat to read images from the network share. Something like http://servername/output/someimage.png Tomcat 7.0.34 was installed as a service using the service.bat, and the service was running under a local account on the webserver, not a local system account, one I created. The docBase was pointing to an administrative share on another storage server. I created the same local account on that storage server, and gave share and security permissions to that share. Then I started Tomcat 7.0.34 and got that exception in the log file. For the heck of it, I removed the 7.0.34 service and installed 7.0.32. The exact same setup is working in 7.0.32 Is the $ causing an issue? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting ciphers
1. The ciphers parameter in Connecter determines the enabled cipher suites in the SSLSocket. See SSLSocket.setEnabledCipherSuites(). That in turn restricts which actual cipher suite can be negotiated with the client, depending also on the client's cipher suites and how JSSE chooses among those that intersect. 2. The private key itself doesn't have any 'supported ciphers' so your question is already meaningless. However (a) it does have a *type*, which is generally RSA or else DH, and (b) it corresponds to a single X.509 certificate which contains a public key in the same type or format. If the server requests a client certificate, it (i.e. JSSE, not Tomcat) sends an SSL CertificateRequest message, which contains a list of acceptable certificate types and a list of acceptable signers. If the client certificate isn't one of those types or isn't signed by one of those signers, it isn't sent, and if the Web resource being requested is defined as requiring SSL client authentication, Tomcat would then deny access. Connection between (1) and (2): zero. EJP -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, 11 January 2013 2:35 PM To: Tomcat Users List Subject: RE: Restricting ciphers its a simple question what does ciphers parameter in Connector have anything to do with the supported ciphers from the key itself the 2 are disconnected please dont waste my time and anyone elses with insults when you are unable to answer this simple question Martin Gainty ___ When Free Speech and Discovery are replaced by Confusion and Obfuscation its time to move Date: Thu, 10 Jan 2013 18:25:02 -0500 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Restricting ciphers -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, Honestly, I'm not sure why I'm feeding the troll at this point. Maybe I'm trying to atone for some horrible crime I can't remember. On 1/10/13 10:05 AM, Martin Gainty wrote: terminology : Nobody was arguing about terminology. Next time, just refer to Wikipedia like everyone else. All you don't know is whether those certificate private key are RSA or DSA algorithms It doesn't matter: you can use RSA (like everyone does) or DSA and that will only determine the type of key you have. The cipher can (and will, since SSL/TLS encryption is symmetric and not PK) use a different algorithm for encryption. you see if it's an RSA or DSA key (along with the key size). Again, key size is only relevant for people who think that bigger is better. You can create a 16k key and it won't be much more secure than an 8k key. Stronger crypto, yes, but nobody tries to guess SSL keys: they use compression (e.g. CRIME) and other nasty tricks so they don't have to do the hard work of key-cracking. cipherGroup is categorised by keysize within cipher-groups (usually a 4digit number which is a power of 2 e.g. 1024 and 2048) Sorry, ciphers and keys are not interchangeable: keys usually have 1k, 2k, 4k, etc. bits in them while symmetric ciphers usually max out at 256-bit key sizes. Try running some of the commands you are grabbing off the web to see what I'm talking about. I've never heard the term cipherGroup. ECB, CBC and PCBC are the usual choices for the optional ModeOfOperation parameter Determining the ALGO-CIPHER supported by your key so we can see that public keys contain a algorithm-cipher combination but how to determine the algo-cipher supported by your key: Sorry, your key can support (essentially) arbitrary ciphers. Your key type has no bearing on whether or not ECB, CBC, etc. can be used. keytool -list -v -keystore fubar.pfx -storetype PKCS12 Here is output: Certificate fingerprints: MD5: SHA1: Signature algorithm name: SHA1withRSA Providers (SUN, SunJCE, SunJSSE,SunRsaSign, IBMJSSE, bcprov-jdkNN-MMM) Lets stick with SunJSSE as our provider supported ciphers will be those ciphers which match SHA1 with RSA from this list: Wrong again: the signature algorithm used to fingerprint your own key has no bearing on the message digests usable for your ciphers. so what you are asking Tomcat Connector to do is 1)export contents of supplied keystoreFile key of keystoreType PKCS12 2)determine Signature algorithm name 3)aggregate cipherSuite by determining Signature specific supported ciphers from Signature algorithm name from http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERef Guide.html 4)reference ciphers attribute from Tomcat Connector 5)determine SignatureSpecificSupportedCiphers from 3) and implement ONLY those ciphers which match exactly to the ciphers listed in Tomcat Connector 5) None of the previous 5 items is accurate. (i have not seen this currently implemented) That's because Tomcat does something else. Actually, JSSE
RE: Restricting ciphers
1. The ciphers parameter in Connecter determines the enabled cipher suites
in the SSLSocket. See SSLSocket.setEnabledCipherSuites(). That in turn
restricts which actual cipher suite can be negotiated with the client,
depending also on the client's cipher suites and how JSSE chooses among
those that intersect. MGunderstood
2. The private key itself doesn't have any 'supported ciphers' so your
question is already meaningless. However (a) it does have a *type*, which is
generally RSA or else DH, and (b) it corresponds to a single X.509
certificate which contains a public key in the same type or format.
MGyes the public key would implement RSA or DH or Idea or some other *type*
If the
server requests a client certificate, it (i.e. JSSE, not Tomcat) sends an
SSL CertificateRequest message, which contains a list of acceptable
certificate types and a list of acceptable signers.
MGthus the choice for cipher suites is now assigned
MGreprising the publicKey signer algorithm to cipher suite
MGWith a RSA (public)key you can nominally use the RSA and DHE_RSA cipher
suite. But if the server certificate has a Key Usage
extension which does not include the keyEncipherment flag, then you are
nominally limited to DHE_RSA.
MGWith a DSA (public) key you can use only a DHE_DSS cipher suite.
MGWith a Diffie-Hellman (public) key, you can use only one of DH_RSA or
DH_DSS, depending on the issuing certificate authority key type.
If the client certificate isn't one of those types or isn't signed by one
of those signers it isn't sent MGthe choice is made! and if the Web
resource being requested is defined
as requiring SSL client authentication, Tomcat would then deny access.
MGlets look at the guts of a public key to clarify whats going on MGkeytool
-list -v -keystore NotForOutsideUse.jks
Keystore type: JKS
Keystore provider: SUN Your keystore contains 1 entry Alias name: Alias
Creation date: Apr 24, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: UID=99, EMAILADDRESS=paynom...@paynomind.com, CN=BigBank,
OU=, O=BigBank.com
Issuer: UID=IssuingAuthority, CN=CanonicalName, OU=IT Security, O=CanonicalName
Serial number:
Valid from: Tue Apr 24 12:21:00 EDT 2012 until: Fri Apr 24 12:21:00 EDT 2015
Certificate fingerprints:
MD5:
SHA1: Signature algorithm name: SHA1withRSA
Version: 3 /snip
lets look at the log produced by TC when Public key =NotForOutsideUse.jks
request is made in the JSSE Key Exchange
keyStore is : NotForOutsideUse.jks
keyStore type is : jks
init keymanager of type SunX509 found key for : {Omitted}
chain [0] = [
[
Version: V3
Subject: UID=99, CN=CanonicalName ID: 99, OU=, O=paynomind.com
Signature Algorithm: SHA1withRSA Key: Sun RSA public key, 2048 bits
modulus: Omitted public exponent: 9
Validity: [From: Fri Dec 10 11:29:21 EST 2010,
To: Mon Dec 09 11:29:21 EST 2013]
Issuer: UID=PayNoMind, CN=CanonicalName, OU=Dept1, O=PayNoMind
SerialNumber: [ Omitted ] EXAMPLE CONCLUSION:
the JSSE Key exchange is implementing SSLV3 Protocol AND RSA Signing Algo
from the eligible ciphers listed here
http://www.openssl.org/docs/apps/ciphers.html could the server implement
IDEA-CBC-SHA cipher (if listed in Tomcat Connector ciphers=IDEA-CBC-SHA
...
My understanding is there can be NO handshake as there is a mismatch
BETWEENSigning Algo already in use (RSA)
with the Signing Algorithm identified by the cipher (IDEA) from the ciphers
parameter
is this not the case?
Connection between (1) and (2): zero. MGagreed
EJP
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Friday, 11 January 2013 2:35 PM
To: Tomcat Users List
Subject: RE: Restricting ciphers
its a simple question what does ciphers parameter in Connector have anything
to do with the supported ciphers from the key itself the 2 are disconnected
please dont waste my time and anyone elses with insults when you are unable
to answer this simple question Martin Gainty
___ When Free Speech and Discovery
are replaced by Confusion and Obfuscation its time to move Date: Thu, 10
Jan 2013 18:25:02 -0500
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Martin,
Honestly, I'm not sure why I'm feeding the troll at this point. Maybe
I'm trying to atone for some horrible crime I can't remember.
On 1/10/13 10:05 AM, Martin Gainty wrote:
terminology :
Nobody was arguing about terminology. Next time, just refer to
Wikipedia like everyone else.
All you don't know is whether those certificate private key are
RSA or DSA algorithms
It doesn't matter: you can use RSA (like everyone does) or DSA and
that will only determine the type
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/11/13 9:26 PM, Martin Gainty wrote: 1. The ciphers parameter in Connecter determines the enabled cipher suites in the SSLSocket. See SSLSocket.setEnabledCipherSuites(). That in turn restricts which actual cipher suite can be negotiated with the client, depending also on the client's cipher suites and how JSSE chooses among those that intersect. MGunderstood 2. The private key itself doesn't have any 'supported ciphers' so your question is already meaningless. However (a) it does have a *type*, which is generally RSA or else DH, and (b) it corresponds to a single X.509 certificate which contains a public key in the same type or format. MGyes the public key would implement RSA or DH or Idea or some other *type* You are still confusing things: IDEA is another symmetric block-cipher like AES, DES, 3DES, etc. Public keys implement nothing: they are just keys algorithms. The algorithms most popular for X509 keys are RSA and DSA. If the server requests a client certificate, it (i.e. JSSE, not Tomcat) sends an SSL CertificateRequest message, which contains a list of acceptable certificate types and a list of acceptable signers. MGthus the choice for cipher suites is now assigned No, this still has nothing to do with cipher suites: the server is telling the client that it's only okay to send X509 (as opposed to some other type of certificate) and that it will only accept certificates that are signed by some authority. (I'm skeptical that the server can actually tell the client that it will only accept, say, Verisign-signed certificates -- I'm fairly sure the client has to send the certificate before the server can reject it). MGreprising the publicKey signer algorithm to cipher suite Not relevant, whatever that means. MGWith a RSA (public)key you can nominally use the RSA and DHE_RSA cipher suite. But if the server certificate has a Key Usage extension which does not include the keyEncipherment flag, then you are nominally limited to DHE_RSA. You do realize that there is a difference between key encipherment (that would be the cipher used to encrypt the key) and data encipherment (the cipher used to encrypt the actual data), right? The former is all about the key and the latter is all about the block cipher used to actually send non-key data back and forth from the client to the server. The cipher suite setting chooses the data encipherment ciphers that are acceptable to the server. An X509 certificate's Key Usage section can only limit the usage of the certificate for various purposes (e.g. encryption, signing, code-signing, email encryption, repudiation, etc. Just Google for X509 Key Usage Extension and you'll find loads of accurate information that you can read instead of us having to teach you about PK infrastructure. MGWith a DSA (public) key you can use only a DHE_DSS cipher suite. I'm waiting for my Amazon ELB to redeploy with a test DSA key (those things are a PITA to create). Running sslscan will see what happens. MGWith a Diffie-Hellman (public) key, you can use only one of DH_RSA or DH_DSS, depending on the issuing certificate authority key type. There is no such thing as a Diffie-Hellman key. D-H is a key /exchange/ protocol. Look: $ openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 ... You can use D-H key exchange with both types of certs (and keys): RSA and DSA. If the client certificate isn't one of those types or isn't signed by one of those signers it isn't sent MGthe choice is made! Note that we're still not talking about cipher suites: we're talking about certificate acceptability, which is part of the key exchange protocol. and if the Web resource being requested is defined as requiring SSL client authentication, Tomcat would then deny access. MGlets look at the guts of a public key to clarify whats going on Let's. MGkeytool -list -v -keystore NotForOutsideUse.jks Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: Alias Creation date: Apr 24, 2012 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: UID=99, EMAILADDRESS=paynom...@paynomind.com, CN=BigBank, OU=, O=BigBank.com Issuer: UID=IssuingAuthority, CN=CanonicalName, OU=IT Security, O=CanonicalName Serial number: Valid from: Tue Apr 24 12:21:00 EDT 2012 until: Fri Apr 24 12:21:00 EDT 2015 Certificate fingerprints: MD5: SHA1: Signature algorithm name: SHA1withRSA Version: 3 /snip lets look at the log produced by TC when Public key =NotForOutsideUse.jks request is made in the JSSE Key Exchange Note that NotForOutsideUse.jks is a key /store/, not a key. It probably contains a key, but it's got more than that. keyStore is : NotForOutsideUse.jks keyStore type is : jks
