Re: tomcat-user Digest 16 May 2005 21:06:57 -0000 Issue 5633
Hi Peter,
You're a stunner. Thanks very much... your fix works.The file is printed
out nicely and multiple restarts doesn't mess it up.
Danke,
Ankit
[EMAIL PROTECTED]
05/16/2005 05:06 PM
Please respond to
Tomcat Users List [EMAIL PROTECTED]
To
tomcat-user@jakarta.apache.org
cc
Subject
tomcat-user Digest 16 May 2005 21:06:57 - Issue 5633
tomcat-user Digest 16 May 2005 21:06:57 - Issue 5633
- Message from Peter Rossbach [EMAIL PROTECTED] on Mon, 16 May 2005
20:23:43 +0200 -
To:
Tomcat Users List tomcat-user@jakarta.apache.org
Subject:
Re: Admin Application messes up HTTPS Connectors in server.xml
Hey Ankit,
I found the bug and hope you can test my fix at cvs head.
Thanks
Peter
Ankit Shah schrieb:
Hi Peter,
Thanks for your response. I double-checked to make sure that
secure=true
is present. Also, the admin app does write out that attribute. It is
indeed the missing sslProtocol attribute that's the root of all problems.
Here are the 2 connector elements from configs:
Configured Manually. Works fine:
Connector port=1443
maxThreads=15 minSpareThreads=5 maxSpareThreads=10
enableLookups=false disableUploadTimeout=true
maxKeepAliveRequests=1
acceptCount=10 debug=0 scheme=https secure=true
keystorePass=mypassword
keystoreFile=c:\path\to\certificate\file
clientAuth=false sslProtocol=TLS /
Saved by Admin App: Breaks
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 /
To fix the above so that it works:
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 sslProtocol=TLS /
Note that secure=true is printed out by the admin app
I have been investigating the source code to track the file that is doing
the job of saving the connector configuration to disk. It should be one
of
the files belonging to the storeconfig.jar classes. As a stop-gap
arrangement i might tweak the code to force printing that attribute and
over-ride all checks for just that attribute. (Messy ... but it will work
until a more thorough investigation is done. Everyone knows how deadlines
go ... ;) )
Thanks again,
Ankit
[EMAIL PROTECTED]
05/15/2005 06:55 PM
Please respond to
Tomcat Users List [EMAIL PROTECTED]
To
tomcat-user@jakarta.apache.org
cc
Subject
tomcat-user Digest 15 May 2005 22:55:08 - Issue 5626
Message from Peter Rossbach [EMAIL PROTECTED] on Sun, 15 May 2005
20:16:01 +0200 -
To:
Tomcat Users List tomcat-user@jakarta.apache.org
Subject:
Re: Admin Application messes up HTTPS Connectors in server.xml
Hey Ankit,
can it be that you forget the secure=true attribute at your https
connector?
I have look inside Http11Protocol code and find this:
public void setProtocol( String k ) {
setSecure(true);
setAttribute(protocol, k);
}
The sslProtocol=TLS is the default and the StoreConfig
handler delete all defaults before saving.
This is really a bad side effect, but with correct secure attribute
setting it works for me!
This https config is also documented at:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html
When problem still exists, please send your working and breaking
Connector element config from server.xml
Thanks
Peter
Ankit Shah schrieb:
Hi,
The Tomcat admin utility doesn't save the HTTPS connectors properly. It
misses out the 'sslProtocol' attribute and this results in the failed
connector. Does anyone have a fix around this?
The following is the current state of our server:
Tomcat 5.5.9 with 1.4.2 compatibility add-on.
JRE version 1.4.2_05
My Tests and results:
About certificates:
We are using our own keytool generated unsigned certificates.
Everytime i point firefox to the admin app, it will present the
certificate for my approval. I temporarily accept the certificate for my
session.
1. Install tomcat, configure an HTTPS connector
Run the admin app and change a parameter (acceptCount in my case:
raised it from 8 to 10) and click Save and then Commit Changes
Restart tomcat. Restart Firefox. Pointing the browser to the
admin
app homepage will not load anything.
No Certificate presented!!
2. Manually did a diff on server.xml and server.xml.backup . The
difference is the missing 'sslProtocol' attribute. The docs say this
attribute is optional, but that doesn't seem like the case. Added the
attribute manually
sslProtocol=TLS
Restart Tomcat. Restart Firefox. Certificate presented. Admin App
Homepage Loaded.
3. By seeing the server.xml
Re: Admin Application messes up HTTPS Connectors in server.xml
Hi Peter,
Thanks for your response. I double-checked to make sure that secure=true
is present. Also, the admin app does write out that attribute. It is
indeed the missing sslProtocol attribute that's the root of all problems.
Here are the 2 connector elements from configs:
Configured Manually. Works fine:
Connector port=1443
maxThreads=15 minSpareThreads=5 maxSpareThreads=10
enableLookups=false disableUploadTimeout=true
maxKeepAliveRequests=1
acceptCount=10 debug=0 scheme=https secure=true
keystorePass=mypassword
keystoreFile=c:\path\to\certificate\file
clientAuth=false sslProtocol=TLS /
Saved by Admin App: Breaks
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 /
To fix the above so that it works:
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 sslProtocol=TLS /
Note that secure=true is printed out by the admin app
I have been investigating the source code to track the file that is doing
the job of saving the connector configuration to disk. It should be one of
the files belonging to the storeconfig.jar classes. As a stop-gap
arrangement i might tweak the code to force printing that attribute and
over-ride all checks for just that attribute. (Messy ... but it will work
until a more thorough investigation is done. Everyone knows how deadlines
go ... ;) )
Thanks again,
Ankit
[EMAIL PROTECTED]
05/15/2005 06:55 PM
Please respond to
Tomcat Users List [EMAIL PROTECTED]
To
tomcat-user@jakarta.apache.org
cc
Subject
tomcat-user Digest 15 May 2005 22:55:08 - Issue 5626
Message from Peter Rossbach [EMAIL PROTECTED] on Sun, 15 May 2005
20:16:01 +0200 -
To:
Tomcat Users List tomcat-user@jakarta.apache.org
Subject:
Re: Admin Application messes up HTTPS Connectors in server.xml
Hey Ankit,
can it be that you forget the secure=true attribute at your https
connector?
I have look inside Http11Protocol code and find this:
public void setProtocol( String k ) {
setSecure(true);
setAttribute(protocol, k);
}
The sslProtocol=TLS is the default and the StoreConfig
handler delete all defaults before saving.
This is really a bad side effect, but with correct secure attribute
setting it works for me!
This https config is also documented at:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html
When problem still exists, please send your working and breaking
Connector element config from server.xml
Thanks
Peter
Ankit Shah schrieb:
Hi,
The Tomcat admin utility doesn't save the HTTPS connectors properly. It
misses out the 'sslProtocol' attribute and this results in the failed
connector. Does anyone have a fix around this?
The following is the current state of our server:
Tomcat 5.5.9 with 1.4.2 compatibility add-on.
JRE version 1.4.2_05
My Tests and results:
About certificates:
We are using our own keytool generated unsigned certificates.
Everytime i point firefox to the admin app, it will present the
certificate for my approval. I temporarily accept the certificate for my
session.
1. Install tomcat, configure an HTTPS connector
Run the admin app and change a parameter (acceptCount in my case:
raised it from 8 to 10) and click Save and then Commit Changes
Restart tomcat. Restart Firefox. Pointing the browser to the
admin
app homepage will not load anything.
No Certificate presented!!
2. Manually did a diff on server.xml and server.xml.backup . The
difference is the missing 'sslProtocol' attribute. The docs say this
attribute is optional, but that doesn't seem like the case. Added the
attribute manually
sslProtocol=TLS
Restart Tomcat. Restart Firefox. Certificate presented. Admin App
Homepage Loaded.
3. By seeing the server.xml written out by Admin app, it is clear that
only attributes with non-default values are written out.
From the admin app, set SSL Protocol field's value to SSL. Save.
Commit Changes
Restart Tomcat. Restart Firefox. NO Certificate Presented. Admin
App homepage NOT loaded.
In server.xml - sslProtocol attribute is NOT written out.
I also inspected the logs (Generated by Log4J and logging level set to
debug)
Upon save:
bean is updated with sslProtocol's new value
Upon Commit:
the list of attributes for the connector doesn't have sslProtocol
as one of the attributes that will be written out
Can you help me how i can make admin application available for Tomcat
administration by the assigned administrators? What fixes
Re: Admin Application messes up HTTPS Connectors in server.xml
Hi Peter,
Thanks for your response. I double-checked to make sure that secure=true
is present. Also, the admin app does write out that attribute. It is
indeed the missing sslProtocol attribute that's the root of all problems.
Here are the 2 connector elements from configs:
Configured Manually. Works fine:
Connector port=1443
maxThreads=15 minSpareThreads=5 maxSpareThreads=10
enableLookups=false disableUploadTimeout=true
maxKeepAliveRequests=1
acceptCount=10 debug=0 scheme=https secure=true
keystorePass=mypassword
keystoreFile=c:\path\to\certificate\file
clientAuth=false sslProtocol=TLS /
Saved by Admin App: Breaks
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 /
To fix the above so that it works:
Connector port=1443 scheme=https secure=true
keystoreFile=c:\path\to\certificate\file keystorePass=mypassword
maxSpareThreads=10 debug=0 maxThreads=15
maxKeepAliveRequests=1 minSpareThreads=5
clientAuth=false acceptCount=10 sslProtocol=TLS /
Note that secure=true is printed out by the admin app
I have been investigating the source code to track the file that is doing
the job of saving the connector configuration to disk. It should be one of
the files belonging to the storeconfig.jar classes. As a stop-gap
arrangement i might tweak the code to force printing that attribute and
over-ride all checks for just that attribute. (Messy ... but it will work
until a more thorough investigation is done. Everyone knows how deadlines
go ... ;) )
Thanks again,
Ankit
[EMAIL PROTECTED]
05/15/2005 06:55 PM
Please respond to
Tomcat Users List [EMAIL PROTECTED]
To
tomcat-user@jakarta.apache.org
cc
Subject
tomcat-user Digest 15 May 2005 22:55:08 - Issue 5626
Message from Peter Rossbach [EMAIL PROTECTED] on Sun, 15 May 2005
20:16:01 +0200 -
To:
Tomcat Users List tomcat-user@jakarta.apache.org
Subject:
Re: Admin Application messes up HTTPS Connectors in server.xml
Hey Ankit,
can it be that you forget the secure=true attribute at your https
connector?
I have look inside Http11Protocol code and find this:
public void setProtocol( String k ) {
setSecure(true);
setAttribute(protocol, k);
}
The sslProtocol=TLS is the default and the StoreConfig
handler delete all defaults before saving.
This is really a bad side effect, but with correct secure attribute
setting it works for me!
This https config is also documented at:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html
When problem still exists, please send your working and breaking
Connector element config from server.xml
Thanks
Peter
Ankit Shah schrieb:
Hi,
The Tomcat admin utility doesn't save the HTTPS connectors properly. It
misses out the 'sslProtocol' attribute and this results in the failed
connector. Does anyone have a fix around this?
The following is the current state of our server:
Tomcat 5.5.9 with 1.4.2 compatibility add-on.
JRE version 1.4.2_05
My Tests and results:
About certificates:
We are using our own keytool generated unsigned certificates.
Everytime i point firefox to the admin app, it will present the
certificate for my approval. I temporarily accept the certificate for my
session.
1. Install tomcat, configure an HTTPS connector
Run the admin app and change a parameter (acceptCount in my case:
raised it from 8 to 10) and click Save and then Commit Changes
Restart tomcat. Restart Firefox. Pointing the browser to the
admin
app homepage will not load anything.
No Certificate presented!!
2. Manually did a diff on server.xml and server.xml.backup . The
difference is the missing 'sslProtocol' attribute. The docs say this
attribute is optional, but that doesn't seem like the case. Added the
attribute manually
sslProtocol=TLS
Restart Tomcat. Restart Firefox. Certificate presented. Admin App
Homepage Loaded.
3. By seeing the server.xml written out by Admin app, it is clear that
only attributes with non-default values are written out.
From the admin app, set SSL Protocol field's value to SSL. Save.
Commit Changes
Restart Tomcat. Restart Firefox. NO Certificate Presented. Admin
App homepage NOT loaded.
In server.xml - sslProtocol attribute is NOT written out.
I also inspected the logs (Generated by Log4J and logging level set to
debug)
Upon save:
bean is updated with sslProtocol's new value
Upon Commit:
the list of attributes for the connector doesn't have sslProtocol
as one of the attributes that will be written out
Can you help me how i can make admin application available for Tomcat
administration by the assigned administrators? What fixes
Re: tomcat-user Digest 12 May 2005 01:34:48 -0000 Issue 5616
Hi Mark, My jar file is placed in $CATALINA_HOME/server/lib/ Here is the slice of my server.xml Service name=Service-name Engine defaultHost=localhost name=Catalina Realm className=my.realm.classname datasource=datasourcename ... other attributes/ Host docbase=webapps name=localhost/ /Engine /Service Thanks, Ankit [EMAIL PROTECTED] 05/11/2005 09:34 PM Please respond to Tomcat Users List [EMAIL PROTECTED] To tomcat-user@jakarta.apache.org cc Subject tomcat-user Digest 12 May 2005 01:34:48 - Issue 5616 tomcat-user Digest 12 May 2005 01:34:48 - Issue 5616 Topics (messages 126492 through 126521): Re: Issues with Custom Realm in Tomcat 5.5 126492 by: Mark Thomas -- - Message from Mark Thomas [EMAIL PROTECTED] on Wed, 11 May 2005 19:08:15 +0100 - To: Tomcat Users List tomcat-user@jakarta.apache.org Subject: Re: Issues with Custom Realm in Tomcat 5.5 Where are you placing the .jar/.class files for your custom realm? At what level in server.xml is your realm configured? Mark Ankit Shah wrote: Hi everyone, I hope someone can help us with this problem. Current Tomcat settings: Release in use: 5.5.9 along with 1.4.2 compatibility add-on Logging using Log4J JRE version: 1.4.2_05 We have written our own custom realm that essentially extends the standard DataSource Realm. However, we are unable to authenticate users of Tomcat's admin and manager application using our Realm. When setting Log4J logging level to Debug, we discovered the following: 1. The Realm is loaded into the MBean Manager. We see a message 'MBean successfully registered' for our Realm 2. When admin is user is being validated, the log messages say 'ClassLoader error: class not found'. and authentication fails. I am not sure whether it failed to load our Realm (shouldn't happen since already registered with MBean) or something else went missing. We CAN perform authentication using the MemoryRealm that's configured by default. What makes this problem even more strange is our Realm worked successfully with Tomcat 5.5.7 Anyone have ANY suggestions as where can we investigate for this problem, please do respond back Thanks in advance. Ankit
Admin Application messes up HTTPS Connectors in server.xml
Hi, The Tomcat admin utility doesn't save the HTTPS connectors properly. It misses out the 'sslProtocol' attribute and this results in the failed connector. Does anyone have a fix around this? The following is the current state of our server: Tomcat 5.5.9 with 1.4.2 compatibility add-on. JRE version 1.4.2_05 My Tests and results: About certificates: We are using our own keytool generated unsigned certificates. Everytime i point firefox to the admin app, it will present the certificate for my approval. I temporarily accept the certificate for my session. 1. Install tomcat, configure an HTTPS connector Run the admin app and change a parameter (acceptCount in my case: raised it from 8 to 10) and click Save and then Commit Changes Restart tomcat. Restart Firefox. Pointing the browser to the admin app homepage will not load anything. No Certificate presented!! 2. Manually did a diff on server.xml and server.xml.backup . The difference is the missing 'sslProtocol' attribute. The docs say this attribute is optional, but that doesn't seem like the case. Added the attribute manually sslProtocol=TLS Restart Tomcat. Restart Firefox. Certificate presented. Admin App Homepage Loaded. 3. By seeing the server.xml written out by Admin app, it is clear that only attributes with non-default values are written out. From the admin app, set SSL Protocol field's value to SSL. Save. Commit Changes Restart Tomcat. Restart Firefox. NO Certificate Presented. Admin App homepage NOT loaded. In server.xml - sslProtocol attribute is NOT written out. I also inspected the logs (Generated by Log4J and logging level set to debug) Upon save: bean is updated with sslProtocol's new value Upon Commit: the list of attributes for the connector doesn't have sslProtocol as one of the attributes that will be written out Can you help me how i can make admin application available for Tomcat administration by the assigned administrators? What fixes will be needed. If there are any known get-arounds for this. Thanks in advance for all your help and appreciate your patience in reading through my email. Ankit PS: I can mail you the log files if you want (I have about 11 of them, each is 10M). Thanks once again
Issues with Custom Realm in Tomcat 5.5
Hi everyone, I hope someone can help us with this problem. Current Tomcat settings: Release in use: 5.5.9 along with 1.4.2 compatibility add-on Logging using Log4J JRE version: 1.4.2_05 We have written our own custom realm that essentially extends the standard DataSource Realm. However, we are unable to authenticate users of Tomcat's admin and manager application using our Realm. When setting Log4J logging level to Debug, we discovered the following: 1. The Realm is loaded into the MBean Manager. We see a message 'MBean successfully registered' for our Realm 2. When admin is user is being validated, the log messages say 'ClassLoader error: class not found'. and authentication fails. I am not sure whether it failed to load our Realm (shouldn't happen since already registered with MBean) or something else went missing. We CAN perform authentication using the MemoryRealm that's configured by default. What makes this problem even more strange is our Realm worked successfully with Tomcat 5.5.7 Anyone have ANY suggestions as where can we investigate for this problem, please do respond back Thanks in advance. Ankit
Admin Application doesn't save correctly - Tomcat 5.5.7
Hi, We are experiencing a strange problem with the Tomcat admin utility. Upon clicking 'Commit Changes', NOT ALL options are written out to the server.xml file !! Here is the tag that was messed up: Before: Connector port=4443 maxThreads=40 minSpareThreads=10 maxSpareThreads=25 enableLookups=false disableUploadTimeout=true acceptCount=10 debug=0 scheme=https secure=true keystorePass= keystoreFile=C:\path\to\certificate\file clientAuth=false sslProtocol=TLS / After: Connector port=4443 scheme=https secure=true / The only changes we did were to add an environment variable for tomcat. Tomcat Configuration in use: Tomcat version: 5.5.7 with 1.4.2 compatibility kit Platform: Win2K JRE: 1.4.2_05 If anyone has any suggestions/clues as to why this is happenning, please do let us know. Also has anyone else encountered similar problems which they can share with us for our information, that would be great. Thanks in advance, Ankit
