Re: Apache 7, Logrotate
Hallo Rainer, Rainer Jung 27 Oct 2013 14:23 Only for the access log: there's a property checkExists="true", thatwill close the file and reopen it if the access log valve detects thefile has been moved/renamed. That option could be more expensive thoughthen just using an appropriate value for fileDateFormat. great! I did not know about it. Let me try it. So I'm left only with catalina.out. Thank you! Regards,Rainer Michael -To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.orgFor additional commands, e-mail: users-h...@tomcat.apache.org Konstantin Kolinko 25 Oct 2013 11:54 2013/10/25 Web2 Solutions m...@web2-solutions.com: Hallo All, I've installed tomcat 7.0.42 and due heavy use my catalina.out and localhost_access-jjj-mm-dd.txt grows quit big. I've successfully configured logrotate to rotate both files. I've removed the date from the access log. So Tomcat now writes without rotating into localhost_access.txt Logrotate now create a new file (localhost_access-dd-mm-dd.txt) and makes localhost_access.txt empty. But tomcat now writes into the new localhost_access-dd-mm-dd.txt instead of the configured file (localhost_access.txt). FYI: You can configure the filename pattern so that it rotates more frequently, e.g. every hour or every ten minutes. What do I have todo so that tomcat continues to write into localhost_access.txt even after rotating? Renaming the file is futile, because Tomcat (for access logs) or the shell (for catalina.out) has the file open and continues to write to it, regardless of the file name. You can use copytruncate option of logrotate. FYI: catalina.out is not a proper log file, but a redirection of stdout (as managed in catalina.sh script that launches Tomcat java process). If a system is configured properly, this file is usually empty. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Web2 Solutions 25 Oct 2013 00:33 Hallo All, I've installed tomcat 7.0.42 and due heavy use my catalina.out and localhost_access-jjj-mm-dd.txt grows quit big. I've successfully configured logrotate to rotate both files. I've removed the date from the access log. So Tomcat now writes without rotating into localhost_access.txt Logrotate now create a new file (localhost_access-dd-mm-dd.txt) and makes localhost_access.txt empty. But tomcat now writes into the new localhost_access-dd-mm-dd.txt instead of the configured file (localhost_access.txt). What do I have todo so that tomcat continues to write into localhost_access.txt even after rotating? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about websockets origin and remote addresses
On 27/10/2013 20:53, Marcelo v wrote: Hello My name is Marcelo, i have a little web site and i am using apache tomcat 8.0.0-RC5 and making use of JSR-356 websocket api ... (i followed the ChatAnnotation example) ... I almost finished the development when i found 2 problems ... 1) Is it possible to get the remote ip of the client on @OnOpen method ??? i was not able to find this answer No. Generally this type of information is available at the handshake which occurs before OnOpen but client IP is not one of the pieces of information exposed. 2) Is it possible to know the origin of connections ??? i mean the domain of the page the connection was made ServerEndpointConfig.Configurator.checkOrigin(String) You'll need a custom Configurator. The first question is because i have a list of banned addresses already ... You might be better blocking these earlier e.g. with iptables or similar. The second is because i need a minimal check on that, because it is not allowed the connections to be made from anywhere ... Keep in mid that a malicious client can forge the origin header. It is the first question i make here ... probably there is not enough information .. please let me know ... No problems. All the relevant information was in the question. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.47 Websocket + JNDI problems
On 27/10/2013 22:41, Konstantin Kolinko wrote: 2013/10/28 Francesco Bassi fvba...@gmail.com: Hello everybody. I just downloaded 7.0.47 and updated one web application that I developed in order to use the new standard JSR 356 websocket implementation. With this new implementation, I noticed that during the processing of incoming websocket events, it's not possible to access the JNDI resources. ie: Context initCtx = new InitialContext(); Context c = (Context) initCtx.lookup(java:comp/env); gives javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. I'm using a custom ServerEndpointConfig.Configurator. Everything used to work properly with the old custom tomcat implementation. Is it an expected behaviour? I think it means that the thread where you process those events does not have its Thread.getContextClassLoader() (aka TCCL) configured and thus JNDI does not know to what web application this thread belongs. Can you provide the stack trace of the place where you access JNDI and check what is the value of Thread.currentThread().getContextClassLoader() there? If the class loader is not a o.a.c.loader.WebappClassLoader one, I think it is OK to create a bugzilla issue. Agreed. I'll see if I can find the bug by code inspection but a stack trace would be quicker. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache2 mod_jk segfaults with OS X Mavericks
Please see interleaved. This is off list so you can object to my
interference :)
Sent from my mobile so please forgive any auto correct errors
Kind regards,
Brett
On 24 Oct 2013 22:55, Christopher Schultz ch...@christopherschultz.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
On 10/24/13, 4:33 PM, Christopher Schultz wrote:
All,
On 10/24/13, 4:11 PM, Christopher Schultz wrote:
Peter,
On 10/24/13, 12:25 PM, Peter Aarestad wrote:
Actually, here's the patch I just did, based on the comments in
that bug report
Here is my preferred patch:
Er, that's not going to work ;)
I'm actively working on this, now, so it shouldn't be long. ;)
Once I realized I was editing the wrong copy of the file, development
on this went much more quickly ;)
Index: native/common/jk_map.c
===
- --- native/common/jk_map.c(revision 1535519)
+++ native/common/jk_map.c (working copy)
@@ -189,13 +189,15 @@
int int_res;
int multit = 1;
- -sprintf(buf, %d, def);
- -rc = jk_map_get_string(m, name, buf);
+rc = jk_map_get_string(m, name, NULL);
+if(NULL == rc) {
+int_res = def;
+} else {
len = strlen(rc);
if (len) {
char *lastchar = buf[0] + len - 1;
- -strcpy(buf, rc);
+strncpy(buf, rc, 100);
Rather than 100 shouldn't that be sizeof(buf) - 1
Or even min(sizeof(buf)-1, len) ? And then handle the null terminator
explicitly?
I can't see the whole file as I'm on a bus!
if ('m' == *lastchar || 'M' == *lastchar) {
*lastchar = '\0';
multit = 1024 * 1024;
@@ -208,6 +210,7 @@
}
else
int_res = def;
+}
return int_res * multit;
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSaYfyAAoJEBzwKT+lPKRYoGUP/1pMlAMnnzzawQ1oLoGUmuFL
jFcVtrVr2R1cFNXof9bj/lVY69qOj7eJd4QRM61C8kQH85pQbX18O1vYg6ALxaT3
Mlm1EIKOSluECbb3yCax+w+/BKXI1jlI9o57D1MYvjFlpXVKwex9Hsd6ERYelqFy
ol1GUhb42zakw/CSFz2yAddqxFVWCQPFCAc2u4tCfEsmmUwOOOtyz/tZrkQNVRPd
aNBSdpfXXlQxMqRi3GkbQq6HRBAduuu7WUrYdmSC3CCb1NC/YoTMCVhND1KAX/PD
0WWZL5SEaBNLOP4a4zp5DZ5XRh4pqEHOofBknaO3Y9ucp5kqAcJfdRQ+slunCvjf
pOfXVAyAr24pFROIItQcAdtO45VG7lkLbxG66SuAnBdorp/kBjdFJwDVXR8yjjay
ig4z1vWOdLCQ9mXzaHseWPjue3fZ92Q9dCDs5vdHAOiYcF/y9o1fjcGX7YIvY43C
vM3mHi2+1W/mwrf+Dey92jHsrMpNqsgTnJmxw0k78Y6rZLBdzwFhsy22MYiGCcEy
sJCWnHHtHuiboQoEBs78wgq/7TivX7xgyMATEYBYiUYHU24l/uY4yitbZndh9ukx
iddr/0MTtXnj44JSnZSHqfct1/PGQVaQR0XucH4PRnFye8SUhgcjTOiP/Z0ZGGso
eJKkBEcXlq7Pv36TW1qK
=fSvA
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.47 Websocket + JNDI problems
On 28/10/2013 08:49, Mark Thomas wrote: On 27/10/2013 22:41, Konstantin Kolinko wrote: 2013/10/28 Francesco Bassi fvba...@gmail.com: Hello everybody. I just downloaded 7.0.47 and updated one web application that I developed in order to use the new standard JSR 356 websocket implementation. With this new implementation, I noticed that during the processing of incoming websocket events, it's not possible to access the JNDI resources. ie: Context initCtx = new InitialContext(); Context c = (Context) initCtx.lookup(java:comp/env); gives javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. I'm using a custom ServerEndpointConfig.Configurator. Everything used to work properly with the old custom tomcat implementation. Is it an expected behaviour? I think it means that the thread where you process those events does not have its Thread.getContextClassLoader() (aka TCCL) configured and thus JNDI does not know to what web application this thread belongs. Can you provide the stack trace of the place where you access JNDI and check what is the value of Thread.currentThread().getContextClassLoader() there? If the class loader is not a o.a.c.loader.WebappClassLoader one, I think it is OK to create a bugzilla issue. Agreed. I'll see if I can find the bug by code inspection but a stack trace would be quicker. I think I've found all the places this can happen and I've fixed them for 8.0.x and 7.0.x. If you could test with either of those (you'll need to build the latest 7.0.x or 8.0.x from svn) to confirm that the fix works for you that would be very helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Configuring Combined Realm
How can I configure CombinedRealm in order to: (1) use JDBCRealm for my webapp with form-based authentication while (2) also using the default UserDatabaseRealm for the Tomcat Web Application Manager? I can get one or the other to work, but not both. Here are the details of my setup: -OS: Windows 7 -Server: Tomcat 7.0.42 -Database: MySQL 5.6 Articles I have used up to this point: 1. Form-based authentication with Tomcat 7 and MySQL: http://www.thejavageek.com/2013/07/07/configure-jdbcrealm-jaas-for-mysql-and -tomcat-7-with-form-based-authentication/ 2. Configuring CombinedRealm: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm 3. Lastly, note that my database, tables, and Connector/J are setup per instructions above and I am able to login to my webapp with form-based authentication when only using JDBCRealm, but I then can't login to the Tomcat Web Application Manager. I configured the file CATALINA_HOME/config/server.xml in two ways: 1. I've identified the following global resources: !--Resource for Tomcat Web App Manager-- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / !--Resource for my webapp-- Resource name=jdbc/authority auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver description=mySQL Database url=jdbc:mysql://localhost:3306/authority maxActive=15 maxidle=3/ 2. I've nested Realms within CombinedRealm as follows: Realm className=org.apache.catalina.realm.CombinedRealm !-- LockOutRealm to prevent brute-force attack. -- Realm className=org.apache.catalina.realm.LockOutRealm failureCount=3 lockoutTime=3600/ !-- Default Realm for Tomcat Application Manager -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !-- JDBC Realm for my webapp. -- Realm className=org.apache.catalina.realm.JDBCRealm driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://localhost:3306/authority connectionName=root connectionPassword=root userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/ /Realm Lastly, I configured my CATALINA_HOME/webapps/[mywebapp]/WEB-INF/web.xml file as follows: ?xml version=1.0 encoding=ISO-8859-1? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-namewebapp/display-name descriptionForm-Based Authentication with mySQL/description resource-ref descriptionmySQL Database/description res-ref-namejdbc/authority/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection web-resource-nameProtected/web-resource-name url-pattern/*/url-pattern http-methodPUT/http-method http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namewebappuser/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/error.jsp/form-error-page /form-login-config /login-config /web-app
Re: Configuring Combined Realm
Hello Brian, On Mo, 2013-10-28 at 07:46 -0400, J. Brian Hall wrote: How can I configure CombinedRealm in order to: (1) use JDBCRealm for my webapp with form-based authentication while (2) also using the default UserDatabaseRealm for the Tomcat Web Application Manager? I can get one or the other to work, but not both. Here are the details of my setup: you don't need CombinedRealm to setup two different Realms for two different contexts (webapps). In fact, it is not what you want. Just put the realm definitions into the contexts for the webapps. So the context for your webapp - I will name it appA - would probably be something like this (file: $CATALINA_BASE/conf/Catalina/localhost/appA.xml or $CATALINA_BASE/webapps/appA/META-INF/context.xml) Context Realm className=org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/authority... / ... /Context While the context definition for the manager application would take the realm definition for the UserDatabaseRealm (file: $CATALINA_BASE/conf/Catalina/localhost/manager.xml or $CATALINA_BASE/webapps/manager/META-INF/context.xml) Context antiResourceLocking=false privileged=true Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ ... /Context You can wrap those realms with the LockOutRealm as done in your examples, of course. Note, that I replaced JDBCRealm with DataSourceRealm, since it is better suited for production. Look at http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#DataSourceRealm for more details to configure it. Regards Felix -OS: Windows 7 -Server: Tomcat 7.0.42 -Database: MySQL 5.6 Articles I have used up to this point: 1. Form-based authentication with Tomcat 7 and MySQL: http://www.thejavageek.com/2013/07/07/configure-jdbcrealm-jaas-for-mysql-and -tomcat-7-with-form-based-authentication/ 2. Configuring CombinedRealm: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm 3. Lastly, note that my database, tables, and Connector/J are setup per instructions above and I am able to login to my webapp with form-based authentication when only using JDBCRealm, but I then can't login to the Tomcat Web Application Manager. I configured the file CATALINA_HOME/config/server.xml in two ways: 1. I've identified the following global resources: !--Resource for Tomcat Web App Manager-- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / !--Resource for my webapp-- Resource name=jdbc/authority auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver description=mySQL Database url=jdbc:mysql://localhost:3306/authority maxActive=15 maxidle=3/ 2. I've nested Realms within CombinedRealm as follows: Realm className=org.apache.catalina.realm.CombinedRealm !-- LockOutRealm to prevent brute-force attack. -- Realm className=org.apache.catalina.realm.LockOutRealm failureCount=3 lockoutTime=3600/ !-- Default Realm for Tomcat Application Manager -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !-- JDBC Realm for my webapp. -- Realm className=org.apache.catalina.realm.JDBCRealm driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://localhost:3306/authority connectionName=root connectionPassword=root userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/ /Realm Lastly, I configured my CATALINA_HOME/webapps/[mywebapp]/WEB-INF/web.xml file as follows: ?xml version=1.0 encoding=ISO-8859-1? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-namewebapp/display-name descriptionForm-Based Authentication with mySQL/description resource-ref descriptionmySQL Database/description res-ref-namejdbc/authority/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection
RE: Configuring Combined Realm
Folks, please ignore my question. I found the problem. Basically, I had the same username / password combination in both databases used under CombinedRealm, (which would be fine) but the associated role_name was different and that's what caused the problem. In any event, all is working. Sorry for the fuss. From: J. Brian Hall [mailto:jbrianhall...@me.com] Sent: Monday, October 28, 2013 7:46 AM To: 'users@tomcat.apache.org' Subject: Configuring Combined Realm How can I configure CombinedRealm in order to: (1) use JDBCRealm for my webapp with form-based authentication while (2) also using the default UserDatabaseRealm for the Tomcat Web Application Manager? I can get one or the other to work, but not both. Here are the details of my setup: -OS: Windows 7 -Server: Tomcat 7.0.42 -Database: MySQL 5.6 Articles I have used up to this point: 1. Form-based authentication with Tomcat 7 and MySQL: http://www.thejavageek.com/2013/07/07/configure-jdbcrealm-jaas-for-mysql-and -tomcat-7-with-form-based-authentication/ 2. Configuring CombinedRealm: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm 3. Lastly, note that my database, tables, and Connector/J are setup per instructions above and I am able to login to my webapp with form-based authentication when only using JDBCRealm, but I then can't login to the Tomcat Web Application Manager. I configured the file CATALINA_HOME/config/server.xml in two ways: 1. I've identified the following global resources: !--Resource for Tomcat Web App Manager-- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / !--Resource for my webapp-- Resource name=jdbc/authority auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver description=mySQL Database url=jdbc:mysql://localhost:3306/authority maxActive=15 maxidle=3/ 2. I've nested Realms within CombinedRealm as follows: Realm className=org.apache.catalina.realm.CombinedRealm !-- LockOutRealm to prevent brute-force attack. -- Realm className=org.apache.catalina.realm.LockOutRealm failureCount=3 lockoutTime=3600/ !-- Default Realm for Tomcat Application Manager -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !-- JDBC Realm for my webapp. -- Realm className=org.apache.catalina.realm.JDBCRealm driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://localhost:3306/authority connectionName=root connectionPassword=root userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/ /Realm Lastly, I configured my CATALINA_HOME/webapps/[mywebapp]/WEB-INF/web.xml file as follows: ?xml version=1.0 encoding=ISO-8859-1? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd http://java.sun.com/xml/ns/j2ee%20http:/java.sun.com/xml/ns/j2ee/web-app_2_ 4.xsd display-namewebapp/display-name descriptionForm-Based Authentication with mySQL/description resource-ref descriptionmySQL Database/description res-ref-namejdbc/authority/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection web-resource-nameProtected/web-resource-name url-pattern/*/url-pattern http-methodPUT/http-method http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namewebappuser/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/error.jsp/form-error-page /form-login-config /login-config /web-app
RE: Configuring Combined Realm
Hey Felix, thanks much. This is a better alternative for what I am doing. -Original Message- From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] Sent: Monday, October 28, 2013 8:38 AM To: Tomcat Users List Subject: Re: Configuring Combined Realm Hello Brian, On Mo, 2013-10-28 at 07:46 -0400, J. Brian Hall wrote: How can I configure CombinedRealm in order to: (1) use JDBCRealm for my webapp with form-based authentication while (2) also using the default UserDatabaseRealm for the Tomcat Web Application Manager? I can get one or the other to work, but not both. Here are the details of my setup: you don't need CombinedRealm to setup two different Realms for two different contexts (webapps). In fact, it is not what you want. Just put the realm definitions into the contexts for the webapps. So the context for your webapp - I will name it appA - would probably be something like this (file: $CATALINA_BASE/conf/Catalina/localhost/appA.xml or $CATALINA_BASE/webapps/appA/META-INF/context.xml) Context Realm className=org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/authority... / ... /Context While the context definition for the manager application would take the realm definition for the UserDatabaseRealm (file: $CATALINA_BASE/conf/Catalina/localhost/manager.xml or $CATALINA_BASE/webapps/manager/META-INF/context.xml) Context antiResourceLocking=false privileged=true Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ ... /Context You can wrap those realms with the LockOutRealm as done in your examples, of course. Note, that I replaced JDBCRealm with DataSourceRealm, since it is better suited for production. Look at http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#DataSourceRealm for more details to configure it. Regards Felix -OS: Windows 7 -Server: Tomcat 7.0.42 -Database: MySQL 5.6 Articles I have used up to this point: 1. Form-based authentication with Tomcat 7 and MySQL: http://www.thejavageek.com/2013/07/07/configure-jdbcrealm-jaas-for-mys ql-and -tomcat-7-with-form-based-authentication/ 2. Configuring CombinedRealm: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm 3. Lastly, note that my database, tables, and Connector/J are setup per instructions above and I am able to login to my webapp with form-based authentication when only using JDBCRealm, but I then can't login to the Tomcat Web Application Manager. I configured the file CATALINA_HOME/config/server.xml in two ways: 1. I've identified the following global resources: !--Resource for Tomcat Web App Manager-- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / !--Resource for my webapp-- Resource name=jdbc/authority auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver description=mySQL Database url=jdbc:mysql://localhost:3306/authority maxActive=15 maxidle=3/ 2. I've nested Realms within CombinedRealm as follows: Realm className=org.apache.catalina.realm.CombinedRealm !-- LockOutRealm to prevent brute-force attack. -- Realm className=org.apache.catalina.realm.LockOutRealm failureCount=3 lockoutTime=3600/ !-- Default Realm for Tomcat Application Manager -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ !-- JDBC Realm for my webapp. -- Realm className=org.apache.catalina.realm.JDBCRealm driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://localhost:3306/authority connectionName=root connectionPassword=root userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/ /Realm Lastly, I configured my CATALINA_HOME/webapps/[mywebapp]/WEB-INF/web.xml file as follows: ?xml version=1.0 encoding=ISO-8859-1? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-namewebapp/display-name descriptionForm-Based Authentication with mySQL/description resource-ref descriptionmySQL Database/description
Re: [ANN] Apache Tomcat 7.0.47 released
2013/10/27 Johan Compagner jcompag...@servoy.com i guess this page should now be updated: http://tomcat.apache.org/whichversion.html Thanks for pointing that. It should be fixed now. only that the minimum version of Tomcat 7 is now not always java 6 ;) fixed
RE: Some Websocket (Async) questions
Hi Mark, thanks a lot for your reply. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, October 23, 2013 8:58 PM To: Tomcat Users List Subject: Re: Some Websocket (Async) questions On 23/10/2013 14:09, Konstantin Preißer wrote: 1) How to asynchronously close / abort a Websocket session? async close would require an API change. abort also requires an API change. Both look fairly easy to implement on the face of it. I'd suggest raising an enhancement request for the WebSocket JSR and then we can consider a Tomcat specific extension to WsSession to implement it until the spec catches up. We can probably agree some standard method signature amongst the implementations (or at least a few of them) on the WebSocket EG list first which should ease the migration pain. OK, I have created an enhancement request here: https://java.net/jira/browse/WEBSOCKET_SPEC-216 2) It seems that when using RemoteEndpoint.Basic to send data synchronously and the remote endpoint does not read from the TCP connection, then a TimeoutException (wrapped in IOException) is thrown several seconds after calling send(). However, when using RemoteEndpoint.Async to send data asynchronously, this is not the case - the SendHandler is not called until the remote endpoint continues to read data. Is there some configuration to set a Timeout for async sending? RemoteEndpoint.Async.setSendTimeout() The problem is that the spec doesn't define a timeout for blcoking IO hence why Tomcat has the org.apache.tomcat.websocket.BLOCKING_SEND_TIMEOUT user property for the session. OK, thanks. 3) It seems that session.close() will call the onClose method of the Endpoint, even if this was called inside of another event handling method like onMessage. Why shouldn't it? Why is this a problem? I don't think it is a problem - just wanted to confirm that this is intended behavior, as it may be a bit confusing to someone familiar with the JavaScript implementation, expecting that onClose() is only called after onMessage() returns. 4) Tomcat's current implementation of RemoteEndpoint.Async#sendText(String, SendHandler) can cause StackOverflowErrors (and seems to contradict Oracle's JavaDoc). That is a bug. Although changing it is only going to make things slower. Ok, thanks for the confirmation. 5) Thread safety for Endpoint The javadoc of class javax.websocket.Endpoint says: Each instance of a websocket endpoint is guaranteed not to be called by more than one thread at a time per active connection. As I'm not a native english speaker, I'm not sure if I understand exactly what this means. By default there is one endpoint instance per connection. In this case there will only ever be one container thread accessing the Endpoint at any one time. However, you can configure things so an endpoint serves multiple connections (much like a Servlet does). In this case there may well be multiple threads accessing the endpoint at the same time but each thread will be associated with the connection for a different client. Containers are free to recycle container objects such as sessions if they wish. It would be foolish in the extreme for a container to try and recycle a application provided object (such as an Endpoint instance) as there is no API for the container to use to recycle the object. Thanks, that makes sense. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some Websocket (Async) questions
On 28/10/2013 13:49, Konstantin Preißer wrote: Hi Mark, thanks a lot for your reply. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, October 23, 2013 8:58 PM To: Tomcat Users List Subject: Re: Some Websocket (Async) questions On 23/10/2013 14:09, Konstantin Preißer wrote: 1) How to asynchronously close / abort a Websocket session? async close would require an API change. abort also requires an API change. Both look fairly easy to implement on the face of it. I'd suggest raising an enhancement request for the WebSocket JSR and then we can consider a Tomcat specific extension to WsSession to implement it until the spec catches up. We can probably agree some standard method signature amongst the implementations (or at least a few of them) on the WebSocket EG list first which should ease the migration pain. OK, I have created an enhancement request here: https://java.net/jira/browse/WEBSOCKET_SPEC-216 2) It seems that when using RemoteEndpoint.Basic to send data synchronously and the remote endpoint does not read from the TCP connection, then a TimeoutException (wrapped in IOException) is thrown several seconds after calling send(). However, when using RemoteEndpoint.Async to send data asynchronously, this is not the case - the SendHandler is not called until the remote endpoint continues to read data. Is there some configuration to set a Timeout for async sending? RemoteEndpoint.Async.setSendTimeout() The problem is that the spec doesn't define a timeout for blcoking IO hence why Tomcat has the org.apache.tomcat.websocket.BLOCKING_SEND_TIMEOUT user property for the session. OK, thanks. 3) It seems that session.close() will call the onClose method of the Endpoint, even if this was called inside of another event handling method like onMessage. Why shouldn't it? Why is this a problem? I don't think it is a problem - just wanted to confirm that this is intended behavior, as it may be a bit confusing to someone familiar with the JavaScript implementation, expecting that onClose() is only called after onMessage() returns. 4) Tomcat's current implementation of RemoteEndpoint.Async#sendText(String, SendHandler) can cause StackOverflowErrors (and seems to contradict Oracle's JavaDoc). That is a bug. Although changing it is only going to make things slower. Ok, thanks for the confirmation. If you haven't already, can you create a Bugzilla entry for this so it doesn't get forgotten. Thanks, Mark 5) Thread safety for Endpoint The javadoc of class javax.websocket.Endpoint says: Each instance of a websocket endpoint is guaranteed not to be called by more than one thread at a time per active connection. As I'm not a native english speaker, I'm not sure if I understand exactly what this means. By default there is one endpoint instance per connection. In this case there will only ever be one container thread accessing the Endpoint at any one time. However, you can configure things so an endpoint serves multiple connections (much like a Servlet does). In this case there may well be multiple threads accessing the endpoint at the same time but each thread will be associated with the connection for a different client. Containers are free to recycle container objects such as sessions if they wish. It would be foolish in the extreme for a container to try and recycle a application provided object (such as an Endpoint instance) as there is no API for the container to use to recycle the object. Thanks, that makes sense. Regards, Konstantin Preißer - 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: Secure Tomcat With SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ognjen, On 10/26/13, 6:47 PM, Ognjen Blagojevic wrote: Chris, On 26.10.2013 23:39, Chris Arnold wrote: Tomcat 7.0.42 on SLES11. I am following http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Configuration to secure tomcat. I have uncommented the SSL HTTP section. The configuration section of that doc, importing the certificate: i have a go daddy bundle in crt format. I can download the cert bundle from go daddy for tomcat but it also is a crt file. Do i have to run this exact command: openssl pkcs12 -export -in mycert.crt -inkey mykey.key \ -out mycert.p12 -name tomcat -CAfile myCA.crt \ -caname root -chain It looks ok to me. Does it work for you? It will create PKCS#12 keystore file (mycert.p12), so you may: 1. add parameter keystoreType=pkcs12 to your HTTPS connector, and use that file, or 2. convert PKCS#12 keystore to Java Keystore format, and use default keystore type (JKS). This is both possible, only if you plan to use either BIO or NIO HTTP connector. If you plan to use APR, connector configuration is completely different. I've been having some trouble lately converting keys and certs from OpenSSL format into Java's JKS format. I follow all of the magical incantations I can find online to convert key+cert into a Java keystore but I get no love. Is there a decent guide anywhere for how to do this? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbnYVAAoJEBzwKT+lPKRYa9wP/0OFuBG5EySMixPWt3y/H07w 4AE+P1NI877g4+ec8I2S2y7KGeHi9kxZ/5WzgOwnzGFddt930xVpzlb0FlMiIqZC Y1OAkKSYm92W2+RA6Vf6SkKuHe9t0deDfrhuY87tU1n0JBg4MnQn7jvMxg/sowi5 axb0vuNYrCnMhtW13KtLeSWlgBnZiD3X2jpZkh8tg3O24S31uzxwFEigzIoYpPj+ 3JTNeEeehAUgLe0o9uXC7+3135q4sipL9H32HDses00RhRd6TLYu9nZUsYjN6Kyl 31J3sescbxrDOQ/ex+c1ESmaAbIgnklOP0i5lRE2IqlnH/VFFZKaAhS6qyZPCLW3 ynI/2Tlo4I1ZfIcYpMQh5eFSv8gsATwkh9DaPhnazCdTymlLbaMiuceZvfWHc3/L spI4HIciE1RbAjeiA1TMUIsL/wrtUXelAbG1wegVFPkFKr5wQifk3Bfb2ayoy5pA kckziemb89Rif8wnO1wuA8ZPb4nKdvbX1QfUXIp3KI8GrQ0pM3ixURDelqituPw8 t2Jk3RZ545vukJtOaOeyCtBUwA8Ej44SLz29/tPb5jvhyo9dxwts6HPg0UKqycfB LAd32e6UrO8won0EdPYjgLayvcpo7kNt+KcgaqccvN+LdX/6RkEoiTEQ75ilrxkP DR67odtPTEgKE9nD4EJm =AD/Q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache2 mod_jk segfaults with OS X Mavericks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brett, On 10/28/13, 5:21 AM, Brett Delle Grazie wrote: Please see interleaved. This is off list so you can object to my interference :) Let's move the discussion over to the BZ report: https://issues.apache.org/bugzilla/show_bug.cgi?id=55696 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbnavAAoJEBzwKT+lPKRY6dgP/1psq7d3lIWvFb0FQa77kOcZ AXMfzY/eeposFwOOV8wEDGhNg67bX/KQWP2d2YTzDehJKNC+qGqsnur78+1e0r81 OrgvQUAEyl4lftChCcIENhDBs0OsCU9fh7cwqsSdefq2UYlIKVFk3N67cN5HUP4V 7zmgdGbxhlkKNY3nc9yYpRb8MGNyFPBDkg1MmExl2GXbMrhzUhtWUzbxxDzKhwsB E+co7zN2EATFvop8oT8JFlleX3RCot30LVk2uXZJa05Vb2vNP+IDayYYdbhq1K0a ZSSz0fvDjSorrnhsaiRoWQRtNQylW+lfJAIoEGHo+2zbkbPCvHj6j8rvLWs1vI2Y yOhu5bKMh2Lv6PuwhFW2ltq9HiSgou9wUHw51AwHdeX4B6NBE4Gk91QmOxrtUMH+ 2PB+3YXBPkuE8LwFmtNerWOdW+Hm438+RpYbWX0iNFLzku/4PiQsfBiAVW2LVOXW F2ij6oBt0amo3T40/Va6rcK0MwRkngfJEneo1WCtipz3v9KMQ6EfbZlw/cyjMTtg AfdBqwvkznRz5vlb30MHC3n0+CmO0TQig/jmW8th5rg7tVkEJ0tp0jBbxgT7eny1 Ozusj4R+SmYtrlcdIRHlfzp9ZVFUsRbM5VTF/JLSUeSqxx0PIbwaDjiLTLhmahhE ruJficY/1r1mkoq6g1te =c7UK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 7.0.47 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Violetta, On 10/26/13, 3:59 PM, Violeta Georgieva wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.47. Congratulations on your first release! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbnbbAAoJEBzwKT+lPKRYjikP/0femn/S+8ohmgcA3Kin2tHY t8Y7HPR7R7aqxZhkjcl8RwA5IIHJhHrRH4Tj+g8EKFNKJbM/TIw/7l81rPsHrmE/ Lwm4YdPIgZkpmyOak/WocmC7YW6F/Ua+8LGuJA21138Mkn7OX7fFhdwWEeWM2I4u cudHqa1sbPBfnVp1Q1cxgPahYas648fZEHqcdJaKutM5IorSvozB7BWB5jx9tjXn qQjSsSm88trhbS+SZWJGEKMwITHUuUNGOoqnQD9kGZ3on1ubaB9j0Cb4Es3YVg8g O5deXepYD79MQwYjiZULwKxShLYoY1Cp6UCSWFLlyUp5ZssUL+ussLNX8HwzsYvY 1Z6MOK9vmVAew8ggl0FP7xGQ/ekV58Rr596UBitj56JOtmY3uRW2qxMvin2zTRcS SjaKxt4fIz0vyNyirDJR9aJ8Y4xfMNkw4Dv9lFF8WiB7rArebPPdS/zGtr/txwXd JffyYzb5/gyiao0wTsIox9Y8KvrBTx12ysHm3ssxHUC/UDDNmLszmr6vkjFMS6Jm OASAgIqhrvo5KYw1966+aUonIAEVx6JZCHKlQn7FqyYzYPKMVunR7zJQmsYi1HjL qI1+xmoIuXb3+OZhDy82E2TfbIxRKmZMu9yS2c9OX2n8QKuRw/sTFf9ji35EIUB7 RBLET0AgO4mOW1mwp12L =L2zY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Some Websocket (Async) questions
Mark, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, October 28, 2013 3:26 PM To: Tomcat Users List Subject: Re: Some Websocket (Async) questions 4) Tomcat's current implementation of RemoteEndpoint.Async#sendText(String, SendHandler) can cause StackOverflowErrors (and seems to contradict Oracle's JavaDoc). That is a bug. Although changing it is only going to make things slower. Ok, thanks for the confirmation. If you haven't already, can you create a Bugzilla entry for this so it doesn't get forgotten. Thanks, Mark Done: https://issues.apache.org/bugzilla/show_bug.cgi?id=55715 Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Secure Tomcat With SSL
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Secure Tomcat With SSL I've been having some trouble lately converting keys and certs from OpenSSL format into Java's JKS format. I follow all of the magical incantations I can find online to convert key+cert into a Java keystore but I get no love. Is there a decent guide anywhere for how to do this? - -chris From my book of spells. Used this to configure SSL in Apache httpd for subversion edge. openssl pkcs12 -export -in C:/server.crt -inkey C:/server.key -name svnedge -out C:/server.p12 keytool -importkeystore -srckeystore C:/server.p12 -srcstoretype PKCS12 -destkeystore C:/svnedge.jks Leo
RE: Secure Tomcat With SSL
-Original Message- From: Chris Arnold [mailto:carn...@electrichendrix.com] Sent: Saturday, October 26, 2013 7:47 PM To: Tomcat Users List Subject: Re: Secure Tomcat With SSL Chris, On 26.10.2013 23:39, Chris Arnold wrote: Tomcat 7.0.42 on SLES11. I am following http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Configuration to secure tomcat. I have uncommented the SSL HTTP section. The configuration section of that doc, importing the certificate: i have a go daddy bundle in crt format. I can download the cert bundle from go daddy for tomcat but it also is a crt file. Do i have to run this exact command: openssl pkcs12 -export -in mycert.crt -inkey mykey.key \ -out mycert.p12 -name tomcat -CAfile myCA.crt \ -caname root -chain It looks ok to me. Does it work for you? It doesn't look like it will work as i do not have a ca file. It will create PKCS#12 keystore file (mycert.p12), so you may: 1. add parameter keystoreType=pkcs12 to your HTTPS connector, and use that file, or 2. convert PKCS#12 keystore to Java Keystore format, and use default keystore type (JKS). This is both possible, only if you plan to use either BIO or NIO HTTP connector. If you plan to use APR, connector configuration is completely different. Not sure what either of these are. I just need secure tomcat Chris, If it turns out you are using APR, when you export your signed certificate and CA-bundles, just specify that you want them for apache not tomcat. Then you can reference the files directly in the server.xml. If you are using the java-based connectors, you should ask for tomcat signed certificates, and I think you have to somehow combine them for use in the keystore (it's been a long time since I did that, I'm APR only). In other words, when you request a cert signed for tomcat at GoDaddy, it really means a java keystore compatible certificate. When you select apache it really means an OpenSSL compatible certificate. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secure Tomcat With SSL
Chris, Leo, On 28.10.2013 18:23, Leo Donahue - OETX wrote: I've been having some trouble lately converting keys and certs from OpenSSL format into Java's JKS format. I follow all of the magical incantations I can find online to convert key+cert into a Java keystore but I get no love. Is there a decent guide anywhere for how to do this? From my book of spells. Used this to configure SSL in Apache httpd for subversion edge. openssl pkcs12 -export -in C:/server.crt -inkey C:/server.key -name svnedge -out C:/server.p12 keytool -importkeystore -srckeystore C:/server.p12 -srcstoretype PKCS12 -destkeystore C:/svnedge.jks During TLS handshake, server may respond with complete certificate chain (server certificate with all intermediate certificates) or with incomplete certificate chain (e.g. server certificate, without any/some intermediate certificates). Most servers, around 88% of them, deliver full certificate chain, according to research mentioned here [1]. Complete certificate chain is being recognized as valid by every client that implements TLS (assuming that root CA certificate is in the client keystore). Incomplete certificate chain may be recognized as valid by some TLS clients (e.g. Internet Explorer), using information from X.509v3 extension called Authority Information Access (AIA), or using previously validated certificate chains. Some clients will not recognize incomplete certificate chain as valid (e.g. openssl or Apache HTTPCommons Client). Even the same client may sometimes recognize incomplete certificate chains as valid and sometimes as invalid, thanks to caching of intermediate certificates. Therefore, it is best practice always to deliver complete certificate chain to the client. Having root CA certificate in the chain is unnecessary, as it wastes your bandwidth during TLS handshake (your client already have root CA certificate in its own keystore). Assuming that intermediate certificates (intermediates.pem), server certificate (server.pem) and private key (server.key) are all in PEM format, you need to add option -certfile to command Leo provided: openssl pkcs12 -export -out keystore.p12 -name myserver -in server.pem -inkey server.key -certfile intermediates.pem Verify that the contents of the p12 keystore with: openssl pkcs12 -in keystore.p12 -nokeys You should verify that the certificate chain is complete (up to, but without root CA certificate). Now, you may use that keystore for BIO and NIO connectors: keystoreFile=keystore.p12 keyAlias=myserver keystoreType=pkcs12 Or you may convert it to JKS keystore as Leo suggests. -Ognjen [1] https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c72 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secure Tomcat With SSL
This tool has saved me a few times over: http://sourceforge.net/projects/portecle/ On Mon, Oct 28, 2013 at 4:41 PM, Ognjen Blagojevic ognjen.d.blagoje...@gmail.com wrote: Chris, Leo, On 28.10.2013 18:23, Leo Donahue - OETX wrote: I've been having some trouble lately converting keys and certs from OpenSSL format into Java's JKS format. I follow all of the magical incantations I can find online to convert key+cert into a Java keystore but I get no love. Is there a decent guide anywhere for how to do this? From my book of spells. Used this to configure SSL in Apache httpd for subversion edge. openssl pkcs12 -export -in C:/server.crt -inkey C:/server.key -name svnedge -out C:/server.p12 keytool -importkeystore -srckeystore C:/server.p12 -srcstoretype PKCS12 -destkeystore C:/svnedge.jks During TLS handshake, server may respond with complete certificate chain (server certificate with all intermediate certificates) or with incomplete certificate chain (e.g. server certificate, without any/some intermediate certificates). Most servers, around 88% of them, deliver full certificate chain, according to research mentioned here [1]. Complete certificate chain is being recognized as valid by every client that implements TLS (assuming that root CA certificate is in the client keystore). Incomplete certificate chain may be recognized as valid by some TLS clients (e.g. Internet Explorer), using information from X.509v3 extension called Authority Information Access (AIA), or using previously validated certificate chains. Some clients will not recognize incomplete certificate chain as valid (e.g. openssl or Apache HTTPCommons Client). Even the same client may sometimes recognize incomplete certificate chains as valid and sometimes as invalid, thanks to caching of intermediate certificates. Therefore, it is best practice always to deliver complete certificate chain to the client. Having root CA certificate in the chain is unnecessary, as it wastes your bandwidth during TLS handshake (your client already have root CA certificate in its own keystore). Assuming that intermediate certificates (intermediates.pem), server certificate (server.pem) and private key (server.key) are all in PEM format, you need to add option -certfile to command Leo provided: openssl pkcs12 -export -out keystore.p12 -name myserver -in server.pem -inkey server.key -certfile intermediates.pem Verify that the contents of the p12 keystore with: openssl pkcs12 -in keystore.p12 -nokeys You should verify that the certificate chain is complete (up to, but without root CA certificate). Now, you may use that keystore for BIO and NIO connectors: keystoreFile=keystore.p12 keyAlias=myserver keystoreType=pkcs12 Or you may convert it to JKS keystore as Leo suggests. -Ognjen [1] https://bugzilla.mozilla.org/**show_bug.cgi?id=399324#c72https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c72 --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secure Tomcat With SSL
Let us first determine which connector do you have configured (BIO, NIO or APR), because HTTPS configuration depends on connector type. Could you send your server.xml with comments and sensitive information removed? ?xml version='1.0' encoding='utf-8'? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- Note: A Server is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/server.html -- Server port=8xxx shutdown=SHUTDOWN !-- Security listener. Documentation at /docs/config/listeners.html Listener className=org.apache.catalina.security.SecurityListener / -- !--APR library loader. Documentation at /docs/apr.html -- Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / !--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -- Listener className=org.apache.catalina.core.JasperListener / !-- Prevent memory leaks due to use of particular java/javax APIs-- !-- Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener /-- Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / !-- Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /-- !-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html -- GlobalNamingResources !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=removed / /GlobalNamingResources !-- A Service is a collection of one or more Connectors that share a single Container Note: A Service is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/service.html -- Service name=Catalina !--The connectors can use a shared executor, you can define one or more named thread pools-- !-- Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=150 minSpareThreads=4/ -- !-- A Connector represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector port=xx URIEncoding=UTF-8 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=x maxHttpHeaderSize=32768 / !-- A Connector using the shared thread pool-- !-- Connector executor=tomcatThreadPool port=8080 URIEncoding=UTF-8 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=x maxHttpHeaderSize=32768 / -- !-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation -- Connector port=x URIEncoding=UTF-8 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS maxHttpHeaderSize=32768 / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=x URIEncoding=UTF-8 protocol=AJP/1.3 redirectPort=x / Connector port=x URIEncoding=UTF-8 protocol=org.apache.coyote.http11.Http11Protocol SSLEnabled=true maxThreads=150 scheme=https keystoreFile=/opt/alfresco/alf_data/keystore/ssl.keystore keystorePass=kT9X6oe68t keystoreType=JCEKS secure=true connectionTimeout=24 truststoreFile=/opt/alfresco/alf_data/keystore/ssl.truststore truststorePass=kT9X6oe68t truststoreType=JCEKS clientAuth=want sslProtocol=TLS allowUnsafeLegacyRenegotiation=true maxHttpHeaderSize=32768 / !-- An Engine
Re: Tomcat 7.0.47 Websocket + JNDI problems
I confirm that using the 7.0 trunk from SVN http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk everything is working fine, now. (ie: the current thread classloader is WebappClassLoader and the JNDI context is properly loaded) Thanks a lot for the quick response. On Mon, Oct 28, 2013 at 11:07 AM, Mark Thomas ma...@apache.org wrote: On 28/10/2013 08:49, Mark Thomas wrote: On 27/10/2013 22:41, Konstantin Kolinko wrote: 2013/10/28 Francesco Bassi fvba...@gmail.com: Hello everybody. I just downloaded 7.0.47 and updated one web application that I developed in order to use the new standard JSR 356 websocket implementation. With this new implementation, I noticed that during the processing of incoming websocket events, it's not possible to access the JNDI resources. ie: Context initCtx = new InitialContext(); Context c = (Context) initCtx.lookup(java:comp/env); gives javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. I'm using a custom ServerEndpointConfig.Configurator. Everything used to work properly with the old custom tomcat implementation. Is it an expected behaviour? I think it means that the thread where you process those events does not have its Thread.getContextClassLoader() (aka TCCL) configured and thus JNDI does not know to what web application this thread belongs. Can you provide the stack trace of the place where you access JNDI and check what is the value of Thread.currentThread().getContextClassLoader() there? If the class loader is not a o.a.c.loader.WebappClassLoader one, I think it is OK to create a bugzilla issue. Agreed. I'll see if I can find the bug by code inspection but a stack trace would be quicker. I think I've found all the places this can happen and I've fixed them for 8.0.x and 7.0.x. If you could test with either of those (you'll need to build the latest 7.0.x or 8.0.x from svn) to confirm that the fix works for you that would be very helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.47 Websocket + JNDI problems
On 28/10/2013 21:41, Francesco Bassi wrote: I confirm that using the 7.0 trunk from SVN http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk everything is working fine, now. (ie: the current thread classloader is WebappClassLoader and the JNDI context is properly loaded) Thanks a lot for the quick response. Great. Thanks for the feedback. Mark On Mon, Oct 28, 2013 at 11:07 AM, Mark Thomas ma...@apache.org wrote: On 28/10/2013 08:49, Mark Thomas wrote: On 27/10/2013 22:41, Konstantin Kolinko wrote: 2013/10/28 Francesco Bassi fvba...@gmail.com: Hello everybody. I just downloaded 7.0.47 and updated one web application that I developed in order to use the new standard JSR 356 websocket implementation. With this new implementation, I noticed that during the processing of incoming websocket events, it's not possible to access the JNDI resources. ie: Context initCtx = new InitialContext(); Context c = (Context) initCtx.lookup(java:comp/env); gives javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. I'm using a custom ServerEndpointConfig.Configurator. Everything used to work properly with the old custom tomcat implementation. Is it an expected behaviour? I think it means that the thread where you process those events does not have its Thread.getContextClassLoader() (aka TCCL) configured and thus JNDI does not know to what web application this thread belongs. Can you provide the stack trace of the place where you access JNDI and check what is the value of Thread.currentThread().getContextClassLoader() there? If the class loader is not a o.a.c.loader.WebappClassLoader one, I think it is OK to create a bugzilla issue. Agreed. I'll see if I can find the bug by code inspection but a stack trace would be quicker. I think I've found all the places this can happen and I've fixed them for 8.0.x and 7.0.x. If you could test with either of those (you'll need to build the latest 7.0.x or 8.0.x from svn) to confirm that the fix works for you that would be very helpful. Mark - 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: Secure Tomcat With SSL
Chris, On 28.10.2013 21:45, Chris Arnold wrote: Let us first determine which connector do you have configured (BIO, NIO or APR), because HTTPS configuration depends on connector type. Could you send your server.xml with comments and sensitive information removed? ?xml version='1.0' encoding='utf-8'? !-- Please, remove comments next time, it will make it easier for us to read. Connector port=xx URIEncoding=UTF-8 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=x maxHttpHeaderSize=32768 / ... Connector port=x URIEncoding=UTF-8 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS maxHttpHeaderSize=32768 / ... Connector port=x URIEncoding=UTF-8 protocol=AJP/1.3 redirectPort=x / Connector port=x URIEncoding=UTF-8 protocol=org.apache.coyote.http11.Http11Protocol SSLEnabled=true maxThreads=150 scheme=https keystoreFile=/opt/alfresco/alf_data/keystore/ssl.keystore keystorePass=kT9X6oe68t keystoreType=JCEKS secure=true connectionTimeout=24 truststoreFile=/opt/alfresco/alf_data/keystore/ssl.truststore truststorePass=kT9X6oe68t truststoreType=JCEKS clientAuth=want sslProtocol=TLS allowUnsafeLegacyRenegotiation=true maxHttpHeaderSize=32768 / Ok, so you have four connectors configured. First two of them have attribute protocol=HTTP/1.1, which means that it will automatically select between APR and BIO connector. APR will be selected if apropriate libarary is found on the system. If not, BIO connector will be selected. Note that you dislosed your keystore passwords on public mailing list, so you may consider to change them. Here it is but you will see both being initialized: Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-apr-8080] Ok, so APR library is found, and APR HTTP connector is initialized on port 8080. Second (HTTPS APR auto select) connector probably fails to initialize since you didn't provide necessary files containing key and certificates. Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [ajp-apr-8009] This is third connector in your configuration. It is used for communication between Apache httpd and Apache Tomcat. In case you don't use httpd, you may comment that one out. Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-bio-8443] This is fourth connector from your configuration, and it is BIO connector, since attribute protocol is set to org.apache.coyote.http11.Http11Protocol. It seems to be working fine. Now you have two HTTPS connectors configured, APR (2nd in your configuration) and BIO (fourth in your configuration). APR fails to start. It is not clear from the information you provided so far are you trying to configure APR connector, but I will assume you do, since BIO connector looks configured already. You will have to make sure that ports for APR and BIO connector differs. Now, for APR connector, you don't need keystore, but seperate files for server key, server certificates, and intermediate certificates. Then add those attributes to APR connector: SSLCertificateFile=/home/tomcat/server.cert SSLCertificateKeyFile=/home/tomcat/server.key SSLCertificateChainFile=/home/tomcat/intermediates.pem When you get APR HTTPS connector up and running, to remove weak ciphers from OpenSSL default configuration, I strongly suggest that you also restrict cipher in use, using these two attiributes to connector configuration (*): SSLHonorCipherOrder=true SSLCipherSuite=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS For more info on setting up APR HTTPS connector, please read: https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native -Ognjen (*) As recommeded by Ivan Ristic: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy#/?page=2 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Secure Tomcat With SSL
For over a year I've been looking for a tool to show the RFC 822 name and the PEM Thanks craig! Martin Date: Mon, 28 Oct 2013 16:43:53 -0400 Subject: Re: Secure Tomcat With SSL From: craig.tay...@drivedominion.com To: users@tomcat.apache.org This tool has saved me a few times over: http://sourceforge.net/projects/portecle/ On Mon, Oct 28, 2013 at 4:41 PM, Ognjen Blagojevic ognjen.d.blagoje...@gmail.com wrote: Chris, Leo, On 28.10.2013 18:23, Leo Donahue - OETX wrote: I've been having some trouble lately converting keys and certs from OpenSSL format into Java's JKS format. I follow all of the magical incantations I can find online to convert key+cert into a Java keystore but I get no love. Is there a decent guide anywhere for how to do this? From my book of spells. Used this to configure SSL in Apache httpd for subversion edge. openssl pkcs12 -export -in C:/server.crt -inkey C:/server.key -name svnedge -out C:/server.p12 keytool -importkeystore -srckeystore C:/server.p12 -srcstoretype PKCS12 -destkeystore C:/svnedge.jks During TLS handshake, server may respond with complete certificate chain (server certificate with all intermediate certificates) or with incomplete certificate chain (e.g. server certificate, without any/some intermediate certificates). Most servers, around 88% of them, deliver full certificate chain, according to research mentioned here [1]. Complete certificate chain is being recognized as valid by every client that implements TLS (assuming that root CA certificate is in the client keystore). Incomplete certificate chain may be recognized as valid by some TLS clients (e.g. Internet Explorer), using information from X.509v3 extension called Authority Information Access (AIA), or using previously validated certificate chains. Some clients will not recognize incomplete certificate chain as valid (e.g. openssl or Apache HTTPCommons Client). Even the same client may sometimes recognize incomplete certificate chains as valid and sometimes as invalid, thanks to caching of intermediate certificates. Therefore, it is best practice always to deliver complete certificate chain to the client. Having root CA certificate in the chain is unnecessary, as it wastes your bandwidth during TLS handshake (your client already have root CA certificate in its own keystore). Assuming that intermediate certificates (intermediates.pem), server certificate (server.pem) and private key (server.key) are all in PEM format, you need to add option -certfile to command Leo provided: openssl pkcs12 -export -out keystore.p12 -name myserver -in server.pem -inkey server.key -certfile intermediates.pem Verify that the contents of the p12 keystore with: openssl pkcs12 -in keystore.p12 -nokeys You should verify that the certificate chain is complete (up to, but without root CA certificate). Now, you may use that keystore for BIO and NIO connectors: keystoreFile=keystore.p12 keyAlias=myserver keystoreType=pkcs12 Or you may convert it to JKS keystore as Leo suggests. -Ognjen [1] https://bugzilla.mozilla.org/**show_bug.cgi?id=399324#c72https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c72 --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
In apache-tomcat-7.0.40 want to set Client auth dynamically
Hi All, In server.xml i need to setup clientauth value dynamically .Is there any java apace api available to set value at runtime or any other alternative option ? Connector clientAuth=false ... Thanks and Regards Sushil Kumar Prusty
