You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Cohen, Laurence" <lc...@novetta.com> on 2015/06/16 17:32:45 UTC
Brand new to Tomcat
Hi,
I find myself in a position where I am the only system administrator on a
project that uses tomcat appserver and apache webeserver with a postgres
backend. We have two applications, and before and changeover from mod_ssl
to mod_nss we were able to go over port 80 to grab files out of the
database. The web app in question is listening on port 8007, but proxied
on 443. After we switch to mod_nss, something happened with the
configuration or the Rewrite Rules, where we can not longer use port 80,
although port 443 is working fine.
In server.xml I can see the following connector line:
<Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
executor="tomcatThreadPool"
connectionTimeout="600000"
scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/opt/dse/keystores/keystore.tomcat"
keystorePass="changeit"
truststoreFile="/opt/dse/keystores/truststore.jks"
truststorePass="password" proxyName="testweb01.novetta.com"
proxyPort="443"/>
My first question is, can I add another connector line, proxying to port 80
as so:
<Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
executor="tomcatThreadPool"
connectionTimeout="600000"
scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/opt/dse/keystores/keystore.tomcat"
keystorePass="changeit"
truststoreFile="/opt/dse/keystores/truststore.jks"
truststorePass="password" proxyName="testweb01.novetta.com"
proxyPort="80"/>
Thanks,
Larry Cohen
AW: Brand new to Tomcat
Posted by Thomas Rohde <tr...@ordix.de>.
Hi Larry,
of course you can add several Connector elements in server.xml. But notice that the value of the port attribute (not proxyPort) must be unique. Otherwise the second connector cannot be established at Tomcat startup.
Regards
Thomas
-----Ursprüngliche Nachricht-----
Von: Cohen, Laurence [mailto:lcohen@novetta.com]
Gesendet: Dienstag, 16. Juni 2015 17:33
An: users@tomcat.apache.org
Betreff: Brand new to Tomcat
Hi,
I find myself in a position where I am the only system administrator on a project that uses tomcat appserver and apache webeserver with a postgres backend. We have two applications, and before and changeover from mod_ssl to mod_nss we were able to go over port 80 to grab files out of the database. The web app in question is listening on port 8007, but proxied on 443. After we switch to mod_nss, something happened with the configuration or the Rewrite Rules, where we can not longer use port 80, although port 443 is working fine.
In server.xml I can see the following connector line:
<Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
executor="tomcatThreadPool"
connectionTimeout="600000"
scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/opt/dse/keystores/keystore.tomcat"
keystorePass="changeit"
truststoreFile="/opt/dse/keystores/truststore.jks"
truststorePass="password" proxyName="testweb01.novetta.com"
proxyPort="443"/>
My first question is, can I add another connector line, proxying to port 80 as so:
<Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
executor="tomcatThreadPool"
connectionTimeout="600000"
scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/opt/dse/keystores/keystore.tomcat"
keystorePass="changeit"
truststoreFile="/opt/dse/keystores/truststore.jks"
truststorePass="password" proxyName="testweb01.novetta.com"
proxyPort="80"/>
Thanks,
Larry Cohen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 16/06/2015 16:32, Cohen, Laurence wrote:
> Hi,
>
> I find myself in a position where I am the only system administrator on a
> project that uses tomcat appserver and apache webeserver with a postgres
> backend. We have two applications, and before and changeover from mod_ssl
> to mod_nss we were able to go over port 80 to grab files out of the
> database. The web app in question is listening on port 8007, but proxied
> on 443. After we switch to mod_nss, something happened with the
> configuration or the Rewrite Rules, where we can not longer use port 80,
> although port 443 is working fine.
>
> In server.xml I can see the following connector line:
>
> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
> executor="tomcatThreadPool"
> connectionTimeout="600000"
> scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/opt/dse/keystores/keystore.tomcat"
> keystorePass="changeit"
> truststoreFile="/opt/dse/keystores/truststore.jks"
> truststorePass="password" proxyName="testweb01.novetta.com"
> proxyPort="443"/>
>
> My first question is, can I add another connector line, proxying to port 80
> as so:
>
> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
> executor="tomcatThreadPool"
> connectionTimeout="600000"
> scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/opt/dse/keystores/keystore.tomcat"
> keystorePass="changeit"
> truststoreFile="/opt/dse/keystores/truststore.jks"
> truststorePass="password" proxyName="testweb01.novetta.com"
> proxyPort="80"/>
No.
The combination of address and port must be unique across all
Connectors. To be more specific, you can't have more than one OS socket
listening on an address/port combination
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
On Tue, Jun 16, 2015 at 4:06 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Larry,
>
> On 6/16/15 3:34 PM, Cohen, Laurence wrote:
> > On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Larry,
> >
> > BTW, you're doing great. Thanks for battling-through. See below.
> >
> > On 6/16/15 2:29 PM, Cohen, Laurence wrote:
> >>>> ******* nss.conf.testweb01 *******
> >>>>
> >>>> Listen 443
> >>>>
> >>>> AddType application/x-x509-ca-cert .crt AddType
> >>>> application/x-pkcs7-crl .crl
> >>>>
> >>>> NSSPassPhraseDialog file:/etc/httpd/.password.conf
> >>>> #NSSPassPhraseDialog builtin
> >>>>
> >>>> NSSPassPhraseHelper /usr/sbin/nss_pcache
> >>>>
> >>>> NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100
> >>>> NSSSession3CacheTimeout 86400
> >>>>
> >>>>
> >>>> NSSRandomSeed startup builtin
> >>>>
> >>>>
> >>>> <VirtualHost _default_:443>
> >>>>
> >>>> DocumentRoot "/var/www/docroot" NSSProxyCheckPeerCN Off
> >>>> NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off
> >>>> NSSRenegotiation on NSSRequireSafeNegotiation on
> >>>>
> >>>> NSSCipherSuite
> >>>> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
> l_m
> >
> >>>>
> d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> > 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
> +r
> >
> >
> sa_aes_256_sha
> >>>>
> >>>> NSSProxyCipherSuite
> >>>> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
> l_m
> >
> >>>>
> d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> > 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
> +r
> >
> >
> sa_aes_256_sha
> >>>>
> >>>> NSSProtocol TLSv1 NSSNickname Server-Cert
> >>>> NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP
> >>>> off
> >>>>
> >>>> ProxyPreserveHost On
> >>>>
> >>>>
> >>>> <Location /dse-help> #SSLRenegBufferSize 10486000
> >>>> NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
> >>>> https://testapp01:8007/dse-help
> >>>> <https://testapp01.novetta.com:8007/dse-help>
> >>>> ProxyPassReverse https://testapp01:8007/dse-help
> >>>> <https://testapp01.novetta.com:8007/dse-help> </Location>
> >
> > Okay, good: here's the real meat of the file (repeated over and
> > over, of course). The "Location" matches an incoming URL and then
> > the stuff between the <Location> and </Location> will be effective
> > for requests whose URLs match that pattern.
> >
> > So, for a request for /dse-help, the request is forwarded-over to
> > Tomcat on port 8007 using the https:// protocol. The
> > ProxyPassReverse will re-write response headers like Location and
> > Set-Cookie to make sure they point to the reverse proxy (httpd)
> > server instead of Tomcat (testapp01:8007).
> >
> > This is all you need to get things working. Since the above is
> > from the :443 VirtualHost, you just need to make sure that similar
> > configuration exists in the :80 VirtualHost configuration files.
> >
> >>>> # initialize the SSL headers to a blank value to avoid http
> >>>> header forgeries RequestHeader set SSL_CLIENT_CERT ""
> >>>> RequestHeader set SSL_CIPHER "" RequestHeader set
> >>>> SSL_SESSION_ID "" RequestHeader set SSL_CIPHER_USEKEYSIZE ""
> >
> > I'm not entirely sure:
> >
> > a) How mod_nss expects to send the original HTTPS information to
> > Tomcat b) Whether or not Tomcat is configured to detect this
> > information and make sure it's available to the container/web
> > application c) In what order the "StdEnvVars" and "RequestHeader
> > set" operations take place.
> >
> > I would want to make sure you've got all that right so tht the
> > following takes place:
> >
> > 1. Request comes in 2. Request has HTTPS-related headers stripped
> > 3. Request has HTTPS-related headers added during proxying
> >
> > You might consider using "RequestHeader unset" instead of
> > "RequestHeader set ''". There's no reason to send-over a blank
> > string.
> >
> >>>> RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
> >>>> RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader
> >>>> set SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set
> >>>> SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
> >
> > If you are going to be "setting" each of these with new values,
> > you may as well not bother to "unset" (or "set" them to "")
> > beforehand. I think it's just extra processing that wastes time and
> > doesn't accomplish. Of course, you'll want to verify that I'm
> > correct in that it doesn't matter if you remove the "unsets" before
> > the "sets", but I think you'll be okay.
> >>>> ******* rewwrite.conf.testweb01 *******
> >>>>
> >>>> # # rewrite.conf: # These rules handle all http:// protocol
> >>>> requests. # RewriteEngine on
> >>>>
> >>>> # General: # Disable HTTP TRACE on all requests. RewriteCond
> >>>> %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
> >>>>
> >>>> # General: # Redirect requests to https, EXCEPT for the
> >>>> favicon, User-Defined URLs, System-Defined URLs, DDMS, AOP. #
> >>>> https rewrite rules are found in ssl.conf. RewriteCond
> >>>> %{SERVER_PROTOCOL} !https RewriteCond %{REQUEST_URI}
> >>>> !^/favicon.ico RewriteCond %{REQUEST_URI} !^/mdr/ns
> >>>> RewriteCond %{REQUEST_URI} !^/mdr/irs RewriteCond
> >>>> %{REQUEST_URI} !^/mdr/documents RewriteCond
> >>>> %{REQUEST_URI} !^/dse/uriService RewriteCond
> >>>> %{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
> >>>> !^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
> >>>> RewriteCond %{REQUEST_URI} !^/dse/downloads
> >>>>
> >>>> # query string containing wsdl (e.g.
> >>>> <somepath>/publish?wsdl), let it fetch as http RewriteCond
> >>>> %{QUERY_STRING} !wsdl
> >>>>
> >>>> RewriteRule ^/(.*)$ https://testweb01/$1
> >>>> <https://testweb01.novetta.com/$1> [last,redirect]
> >
> > Oh, man. This is awful.
> >
> > I'll bet the SSL-based configuration was re-written using
> > ProxyPass/ProxyPassReverse and then the mod_rewrite (that's what
> > all this stuff is) stuff was simply removed (or no longer
> > referenced from httpd.conf, probably).
> >
> > But it looks like the RewriteCond/RewriteRule stuff was actually
> > enabling your proxying (in the very ugliest way possible, I might
> > add), so you lost your :80 proxying.
> >
> > For the most part, you should be able to copy the <Location>
> > sections from your nss.conf into whatever file you would like to
> > include to set up your :80 VirtualHost, and that should be about
> > it. (Of course, you'll want to remove the NSSOptions and
> > NSSVerifyClient sections as well.)
> >
> > If you'd prefer to have a slightly cleaner configuration, you can
> > change this:
> >
> >>>> <Location /dse-help> #SSLRenegBufferSize 10486000
> >>>> NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
> >>>> https://testapp01:8007/dse-help
> >>>> <https://testapp01.novetta.com:8007/dse-help>
> >>>> ProxyPassReverse https://testapp01:8007/dse-help
> >>>> <https://testapp01.novetta.com:8007/dse-help> </Location>
> >
> > to this:
> >
> > ProxyPass /dse-help https://testapp01:8007/dse-help
> > ProxyPassReverse /dse-help https://testapp01:8007/dse-help
> >
> > , since you don't need additional configuration.
> >
> > I would be willing to bet that if you set NSSOptions and
> > NSSVerifyClient at the top-level, you wouldn't have to specify it
> > separately in all of those <Location> sections, and your
> > configuration would get even simpler, but I'm not aware of all of
> > the intricacies of your environment, so I wouldn't recommend you
> > make that change without someone watching who knows this
> > configuration very well.
> >
> > Hope that helps, -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> > Thank you Chris. Unfortunately much of what you are saying is over
> > my head. I'm a real newbie.
>
> Okay.
>
> > If you are saying I should set up another file for a :80 Virtual
> > Host, and include it from httpd.conf, can I just pretty much copy
> > what's in the :443 Virtual Host?
>
> I would first find the existing :80 VirtualHost and make sure that
> there is no conflicting configuration in there for what you are about
> to do.
>
> But then, yes, I think you can pretty much copy the <Location>
> sections from nss.conf into the :80 VirtualHost.
>
> Forget what I said about removing the NSSOptions and NSSVerifyClient
> directives, because I think you still need to make sure that you are
> communicating properly between httpd and Tomcat (over SSL). I wouldn't
> want to break that by removing those directives.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVgIG5AAoJEBzwKT+lPKRYBAwQAJitZGirkCLwBoNvodNUeDwZ
> KOLaFuIln4OqYf/wKpNBn/Lio9KlT21KPvquy5WpCgJGu829T+z/lSqMMXgYlcZp
> JArOHlLQJwKZ6u5rZG+E2BacN5JM/uIWgbX8FUw7DIHkIUxmGyRcXXIzpG+v/Bcb
> ne+7aO0IbUlvVRxLoSQ8zUE0u2Xbvu7BLuzk0/RtRblUPwSJU3aHxS6DdZkVuyut
> qbARbmSw7bsbrd1mFBPpSTpTQ6mxOsUkeW0CS4P/yvMqvAcZHh2+uymfWyUhCyUp
> 5k2Qlf/Um8NYimlun8SO6ByA4bfcvBGDAgBB1L2eWajiImjOBI+neZNmQv4t1r90
> 5OeL2FvkfhPviukU56vRdKUmy9RzSRtHQkYKy9YZcPPWIZmKRkZSufGbCNNojXii
> 1LiV76W83tfPVhY5cEbO/dFU3M4ACmoynDEfodMeXkFNWNs+UEBNKNrjXZ1o38vH
> Xl42abh7JlVlyJmIeq9Sh/L0GaibvcOaJ/Ovus2FpghuLDunzd6Kxs2LH3+Z5HVu
> qV2nzSB2gKe48MFVwzh6kTqHxrpOuQocb6aBps3RpjSM2dD2FS/L5hOLf2AtWiwm
> cd/QeC3Be5SjgxJOmjxT8la6MuGJZ4AO05oODLqBu3EjspCWCzKefpLTrWV7MXnC
> 4IXbGlRviOsg7cuWXL+u
> =a8pl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Thank you Chris. I'm playing with it but it's still not working, and I
have to move on to something else now. Thanks for the help though.
Larry Cohen
Re: Brand new to Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Larry,
On 6/16/15 3:34 PM, Cohen, Laurence wrote:
> On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Larry,
>
> BTW, you're doing great. Thanks for battling-through. See below.
>
> On 6/16/15 2:29 PM, Cohen, Laurence wrote:
>>>> ******* nss.conf.testweb01 *******
>>>>
>>>> Listen 443
>>>>
>>>> AddType application/x-x509-ca-cert .crt AddType
>>>> application/x-pkcs7-crl .crl
>>>>
>>>> NSSPassPhraseDialog file:/etc/httpd/.password.conf
>>>> #NSSPassPhraseDialog builtin
>>>>
>>>> NSSPassPhraseHelper /usr/sbin/nss_pcache
>>>>
>>>> NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100
>>>> NSSSession3CacheTimeout 86400
>>>>
>>>>
>>>> NSSRandomSeed startup builtin
>>>>
>>>>
>>>> <VirtualHost _default_:443>
>>>>
>>>> DocumentRoot "/var/www/docroot" NSSProxyCheckPeerCN Off
>>>> NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off
>>>> NSSRenegotiation on NSSRequireSafeNegotiation on
>>>>
>>>> NSSCipherSuite
>>>> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
>
>>>>
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
>
>
sa_aes_256_sha
>>>>
>>>> NSSProxyCipherSuite
>>>> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_nul
l_m
>
>>>>
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,
+r
>
>
sa_aes_256_sha
>>>>
>>>> NSSProtocol TLSv1 NSSNickname Server-Cert
>>>> NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP
>>>> off
>>>>
>>>> ProxyPreserveHost On
>>>>
>>>>
>>>> <Location /dse-help> #SSLRenegBufferSize 10486000
>>>> NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
>>>> https://testapp01:8007/dse-help
>>>> <https://testapp01.novetta.com:8007/dse-help>
>>>> ProxyPassReverse https://testapp01:8007/dse-help
>>>> <https://testapp01.novetta.com:8007/dse-help> </Location>
>
> Okay, good: here's the real meat of the file (repeated over and
> over, of course). The "Location" matches an incoming URL and then
> the stuff between the <Location> and </Location> will be effective
> for requests whose URLs match that pattern.
>
> So, for a request for /dse-help, the request is forwarded-over to
> Tomcat on port 8007 using the https:// protocol. The
> ProxyPassReverse will re-write response headers like Location and
> Set-Cookie to make sure they point to the reverse proxy (httpd)
> server instead of Tomcat (testapp01:8007).
>
> This is all you need to get things working. Since the above is
> from the :443 VirtualHost, you just need to make sure that similar
> configuration exists in the :80 VirtualHost configuration files.
>
>>>> # initialize the SSL headers to a blank value to avoid http
>>>> header forgeries RequestHeader set SSL_CLIENT_CERT ""
>>>> RequestHeader set SSL_CIPHER "" RequestHeader set
>>>> SSL_SESSION_ID "" RequestHeader set SSL_CIPHER_USEKEYSIZE ""
>
> I'm not entirely sure:
>
> a) How mod_nss expects to send the original HTTPS information to
> Tomcat b) Whether or not Tomcat is configured to detect this
> information and make sure it's available to the container/web
> application c) In what order the "StdEnvVars" and "RequestHeader
> set" operations take place.
>
> I would want to make sure you've got all that right so tht the
> following takes place:
>
> 1. Request comes in 2. Request has HTTPS-related headers stripped
> 3. Request has HTTPS-related headers added during proxying
>
> You might consider using "RequestHeader unset" instead of
> "RequestHeader set ''". There's no reason to send-over a blank
> string.
>
>>>> RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
>>>> RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader
>>>> set SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set
>>>> SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
>
> If you are going to be "setting" each of these with new values,
> you may as well not bother to "unset" (or "set" them to "")
> beforehand. I think it's just extra processing that wastes time and
> doesn't accomplish. Of course, you'll want to verify that I'm
> correct in that it doesn't matter if you remove the "unsets" before
> the "sets", but I think you'll be okay.
>>>> ******* rewwrite.conf.testweb01 *******
>>>>
>>>> # # rewrite.conf: # These rules handle all http:// protocol
>>>> requests. # RewriteEngine on
>>>>
>>>> # General: # Disable HTTP TRACE on all requests. RewriteCond
>>>> %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
>>>>
>>>> # General: # Redirect requests to https, EXCEPT for the
>>>> favicon, User-Defined URLs, System-Defined URLs, DDMS, AOP. #
>>>> https rewrite rules are found in ssl.conf. RewriteCond
>>>> %{SERVER_PROTOCOL} !https RewriteCond %{REQUEST_URI}
>>>> !^/favicon.ico RewriteCond %{REQUEST_URI} !^/mdr/ns
>>>> RewriteCond %{REQUEST_URI} !^/mdr/irs RewriteCond
>>>> %{REQUEST_URI} !^/mdr/documents RewriteCond
>>>> %{REQUEST_URI} !^/dse/uriService RewriteCond
>>>> %{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
>>>> !^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
>>>> RewriteCond %{REQUEST_URI} !^/dse/downloads
>>>>
>>>> # query string containing wsdl (e.g.
>>>> <somepath>/publish?wsdl), let it fetch as http RewriteCond
>>>> %{QUERY_STRING} !wsdl
>>>>
>>>> RewriteRule ^/(.*)$ https://testweb01/$1
>>>> <https://testweb01.novetta.com/$1> [last,redirect]
>
> Oh, man. This is awful.
>
> I'll bet the SSL-based configuration was re-written using
> ProxyPass/ProxyPassReverse and then the mod_rewrite (that's what
> all this stuff is) stuff was simply removed (or no longer
> referenced from httpd.conf, probably).
>
> But it looks like the RewriteCond/RewriteRule stuff was actually
> enabling your proxying (in the very ugliest way possible, I might
> add), so you lost your :80 proxying.
>
> For the most part, you should be able to copy the <Location>
> sections from your nss.conf into whatever file you would like to
> include to set up your :80 VirtualHost, and that should be about
> it. (Of course, you'll want to remove the NSSOptions and
> NSSVerifyClient sections as well.)
>
> If you'd prefer to have a slightly cleaner configuration, you can
> change this:
>
>>>> <Location /dse-help> #SSLRenegBufferSize 10486000
>>>> NSSVerifyClient none NSSOptions +StdEnvVars ProxyPass
>>>> https://testapp01:8007/dse-help
>>>> <https://testapp01.novetta.com:8007/dse-help>
>>>> ProxyPassReverse https://testapp01:8007/dse-help
>>>> <https://testapp01.novetta.com:8007/dse-help> </Location>
>
> to this:
>
> ProxyPass /dse-help https://testapp01:8007/dse-help
> ProxyPassReverse /dse-help https://testapp01:8007/dse-help
>
> , since you don't need additional configuration.
>
> I would be willing to bet that if you set NSSOptions and
> NSSVerifyClient at the top-level, you wouldn't have to specify it
> separately in all of those <Location> sections, and your
> configuration would get even simpler, but I'm not aware of all of
> the intricacies of your environment, so I wouldn't recommend you
> make that change without someone watching who knows this
> configuration very well.
>
> Hope that helps, -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> Thank you Chris. Unfortunately much of what you are saying is over
> my head. I'm a real newbie.
Okay.
> If you are saying I should set up another file for a :80 Virtual
> Host, and include it from httpd.conf, can I just pretty much copy
> what's in the :443 Virtual Host?
I would first find the existing :80 VirtualHost and make sure that
there is no conflicting configuration in there for what you are about
to do.
But then, yes, I think you can pretty much copy the <Location>
sections from nss.conf into the :80 VirtualHost.
Forget what I said about removing the NSSOptions and NSSVerifyClient
directives, because I think you still need to make sure that you are
communicating properly between httpd and Tomcat (over SSL). I wouldn't
want to break that by removing those directives.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVgIG5AAoJEBzwKT+lPKRYBAwQAJitZGirkCLwBoNvodNUeDwZ
KOLaFuIln4OqYf/wKpNBn/Lio9KlT21KPvquy5WpCgJGu829T+z/lSqMMXgYlcZp
JArOHlLQJwKZ6u5rZG+E2BacN5JM/uIWgbX8FUw7DIHkIUxmGyRcXXIzpG+v/Bcb
ne+7aO0IbUlvVRxLoSQ8zUE0u2Xbvu7BLuzk0/RtRblUPwSJU3aHxS6DdZkVuyut
qbARbmSw7bsbrd1mFBPpSTpTQ6mxOsUkeW0CS4P/yvMqvAcZHh2+uymfWyUhCyUp
5k2Qlf/Um8NYimlun8SO6ByA4bfcvBGDAgBB1L2eWajiImjOBI+neZNmQv4t1r90
5OeL2FvkfhPviukU56vRdKUmy9RzSRtHQkYKy9YZcPPWIZmKRkZSufGbCNNojXii
1LiV76W83tfPVhY5cEbO/dFU3M4ACmoynDEfodMeXkFNWNs+UEBNKNrjXZ1o38vH
Xl42abh7JlVlyJmIeq9Sh/L0GaibvcOaJ/Ovus2FpghuLDunzd6Kxs2LH3+Z5HVu
qV2nzSB2gKe48MFVwzh6kTqHxrpOuQocb6aBps3RpjSM2dD2FS/L5hOLf2AtWiwm
cd/QeC3Be5SjgxJOmjxT8la6MuGJZ4AO05oODLqBu3EjspCWCzKefpLTrWV7MXnC
4IXbGlRviOsg7cuWXL+u
=a8pl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
On Tue, Jun 16, 2015 at 3:13 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Larry,
>
> BTW, you're doing great. Thanks for battling-through. See below.
>
> On 6/16/15 2:29 PM, Cohen, Laurence wrote:
> > ******* nss.conf.testweb01 *******
> >
> > Listen 443
> >
> > AddType application/x-x509-ca-cert .crt AddType
> > application/x-pkcs7-crl .crl
> >
> > NSSPassPhraseDialog file:/etc/httpd/.password.conf
> > #NSSPassPhraseDialog builtin
> >
> > NSSPassPhraseHelper /usr/sbin/nss_pcache
> >
> > NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100
> > NSSSession3CacheTimeout 86400
> >
> >
> > NSSRandomSeed startup builtin
> >
> >
> > <VirtualHost _default_:443>
> >
> > DocumentRoot "/var/www/docroot" NSSProxyCheckPeerCN Off NSSEngine
> > on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on
> > NSSRequireSafeNegotiation on
> >
> > NSSCipherSuite
> > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
> d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
> sa_aes_256_sha
> >
> > NSSProxyCipherSuite
> > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
> d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
> 8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
> sa_aes_256_sha
> >
> > NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase
> > /etc/httpd/alias NSSFIPS on NSSOCSP off
> >
> > ProxyPreserveHost On
> >
> >
> > <Location /dse-help> #SSLRenegBufferSize 10486000 NSSVerifyClient
> > none NSSOptions +StdEnvVars ProxyPass
> > https://testapp01:8007/dse-help
> > <https://testapp01.novetta.com:8007/dse-help> ProxyPassReverse
> > https://testapp01:8007/dse-help
> > <https://testapp01.novetta.com:8007/dse-help> </Location>
>
> Okay, good: here's the real meat of the file (repeated over and over,
> of course). The "Location" matches an incoming URL and then the stuff
> between the <Location> and </Location> will be effective for requests
> whose URLs match that pattern.
>
> So, for a request for /dse-help, the request is forwarded-over to
> Tomcat on port 8007 using the https:// protocol. The ProxyPassReverse
> will re-write response headers like Location and Set-Cookie to make
> sure they point to the reverse proxy (httpd) server instead of Tomcat
> (testapp01:8007).
>
> This is all you need to get things working. Since the above is from
> the :443 VirtualHost, you just need to make sure that similar
> configuration exists in the :80 VirtualHost configuration files.
>
> > # initialize the SSL headers to a blank value to avoid http header
> > forgeries RequestHeader set SSL_CLIENT_CERT "" RequestHeader set
> > SSL_CIPHER "" RequestHeader set SSL_SESSION_ID "" RequestHeader set
> > SSL_CIPHER_USEKEYSIZE ""
>
> I'm not entirely sure:
>
> a) How mod_nss expects to send the original HTTPS information to Tomcat
> b) Whether or not Tomcat is configured to detect this information and
> make sure it's available to the container/web application
> c) In what order the "StdEnvVars" and "RequestHeader set" operations
> take place.
>
> I would want to make sure you've got all that right so tht the
> following takes place:
>
> 1. Request comes in
> 2. Request has HTTPS-related headers stripped
> 3. Request has HTTPS-related headers added during proxying
>
> You might consider using "RequestHeader unset" instead of
> "RequestHeader set ''". There's no reason to send-over a blank string.
>
> > RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
> > RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader set
> > SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set
> > SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
>
> If you are going to be "setting" each of these with new values, you
> may as well not bother to "unset" (or "set" them to "") beforehand. I
> think it's just extra processing that wastes time and doesn't
> accomplish. Of course, you'll want to verify that I'm correct in that
> it doesn't matter if you remove the "unsets" before the "sets", but I
> think you'll be okay.
> > ******* rewwrite.conf.testweb01 *******
> >
> > # # rewrite.conf: # These rules handle all http:// protocol
> > requests. # RewriteEngine on
> >
> > # General: # Disable HTTP TRACE on all requests. RewriteCond
> > %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
> >
> > # General: # Redirect requests to https, EXCEPT for the favicon,
> > User-Defined URLs, System-Defined URLs, DDMS, AOP. # https rewrite
> > rules are found in ssl.conf. RewriteCond %{SERVER_PROTOCOL}
> > !https RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond
> > %{REQUEST_URI} !^/mdr/ns RewriteCond %{REQUEST_URI}
> > !^/mdr/irs RewriteCond %{REQUEST_URI} !^/mdr/documents
> > RewriteCond %{REQUEST_URI} !^/dse/uriService RewriteCond
> > %{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
> > !^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
> > RewriteCond %{REQUEST_URI} !^/dse/downloads
> >
> > # query string containing wsdl (e.g. <somepath>/publish?wsdl), let
> > it fetch as http RewriteCond %{QUERY_STRING} !wsdl
> >
> > RewriteRule ^/(.*)$ https://testweb01/$1
> > <https://testweb01.novetta.com/$1> [last,redirect]
>
> Oh, man. This is awful.
>
> I'll bet the SSL-based configuration was re-written using
> ProxyPass/ProxyPassReverse and then the mod_rewrite (that's what all
> this stuff is) stuff was simply removed (or no longer referenced from
> httpd.conf, probably).
>
> But it looks like the RewriteCond/RewriteRule stuff was actually
> enabling your proxying (in the very ugliest way possible, I might
> add), so you lost your :80 proxying.
>
> For the most part, you should be able to copy the <Location> sections
> from your nss.conf into whatever file you would like to include to set
> up your :80 VirtualHost, and that should be about it. (Of course,
> you'll want to remove the NSSOptions and NSSVerifyClient sections as
> well.)
>
> If you'd prefer to have a slightly cleaner configuration, you can
> change this:
>
> > <Location /dse-help> #SSLRenegBufferSize 10486000 NSSVerifyClient
> > none NSSOptions +StdEnvVars ProxyPass
> > https://testapp01:8007/dse-help
> > <https://testapp01.novetta.com:8007/dse-help> ProxyPassReverse
> > https://testapp01:8007/dse-help
> > <https://testapp01.novetta.com:8007/dse-help> </Location>
>
> to this:
>
> ProxyPass /dse-help https://testapp01:8007/dse-help
> ProxyPassReverse /dse-help https://testapp01:8007/dse-help
>
> , since you don't need additional configuration.
>
> I would be willing to bet that if you set NSSOptions and
> NSSVerifyClient at the top-level, you wouldn't have to specify it
> separately in all of those <Location> sections, and your configuration
> would get even simpler, but I'm not aware of all of the intricacies of
> your environment, so I wouldn't recommend you make that change without
> someone watching who knows this configuration very well.
>
> Hope that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVgHVRAAoJEBzwKT+lPKRYiGgP+gK5y4zid+1X4v3rKN2Se/Tv
> seEbzhqW8IDigzysqUQAsqklmrNngyb4wbB6BltcPTVzwGiP3wHf1jKRfpXIdat8
> KoXppXFgfL1FMP5HwfNBZhu8qQbv4bnbVPYRdvy5LsYtHIlZjD/BNMQRZKmiHQYk
> cWYLMmqDs/oginqA1E9fDIrx1XZxSJBFL646S7dT3IQOUWxhgOtN3b5WDyZcY6bk
> ZQMkgtALX1lyKDqWB8zVeqppQ9zljuF3dJno5q8E5bERYD98gTTEsnItuI7OeFSI
> jkOtXG7IqmlOTd379q+A024oGubnwNmSeX2xMXwok03pd78okiCfTa46IyI407Se
> eTyzProuCgks8EsDf5oUJflP9c8CVubyCkaI2cKR5APEiQNEqROdKy9IAlS1V2R0
> Zo3mPQ5cq9S84DXPW5DtGdFTNvq7izZaOhRSg+oeUejpelWreVqS3BzkxGf2Kn9i
> uutCCFF7k/OkrzCnUN8ASEEdXOibMJhhGlTjYaChZHmQLFAvocYNcUhUThtahCM+
> LTGIm6thalOKzWEjv3L8OI0NV3F4pD6x6O1/TAMZU3Jq8zJjdiIBNEnOdeAWs/2M
> uzFZA7f4BbpgiDMyM6+GnmHKeXIZwRFE6f94ucEAnwRSGjd/H03URHrig4cUvIK0
> 2IRJtDdgFtrOCIoX8OSD
> =EQaf
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Thank you Chris. Unfortunately much of what you are saying is over my
head. I'm a real newbie. If you are saying I should set up another file
for a :80 Virtual Host, and include it from httpd.conf, can I just pretty
much copy what's in the :443 Virtual Host?
Thanks,
Larry Cohen
Re: Brand new to Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Larry,
BTW, you're doing great. Thanks for battling-through. See below.
On 6/16/15 2:29 PM, Cohen, Laurence wrote:
> ******* nss.conf.testweb01 *******
>
> Listen 443
>
> AddType application/x-x509-ca-cert .crt AddType
> application/x-pkcs7-crl .crl
>
> NSSPassPhraseDialog file:/etc/httpd/.password.conf
> #NSSPassPhraseDialog builtin
>
> NSSPassPhraseHelper /usr/sbin/nss_pcache
>
> NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100
> NSSSession3CacheTimeout 86400
>
>
> NSSRandomSeed startup builtin
>
>
> <VirtualHost _default_:443>
>
> DocumentRoot "/var/www/docroot" NSSProxyCheckPeerCN Off NSSEngine
> on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on
> NSSRequireSafeNegotiation on
>
> NSSCipherSuite
> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
>
> NSSProxyCipherSuite
> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_m
d5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_12
8_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+r
sa_aes_256_sha
>
> NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase
> /etc/httpd/alias NSSFIPS on NSSOCSP off
>
> ProxyPreserveHost On
>
>
> <Location /dse-help> #SSLRenegBufferSize 10486000 NSSVerifyClient
> none NSSOptions +StdEnvVars ProxyPass
> https://testapp01:8007/dse-help
> <https://testapp01.novetta.com:8007/dse-help> ProxyPassReverse
> https://testapp01:8007/dse-help
> <https://testapp01.novetta.com:8007/dse-help> </Location>
Okay, good: here's the real meat of the file (repeated over and over,
of course). The "Location" matches an incoming URL and then the stuff
between the <Location> and </Location> will be effective for requests
whose URLs match that pattern.
So, for a request for /dse-help, the request is forwarded-over to
Tomcat on port 8007 using the https:// protocol. The ProxyPassReverse
will re-write response headers like Location and Set-Cookie to make
sure they point to the reverse proxy (httpd) server instead of Tomcat
(testapp01:8007).
This is all you need to get things working. Since the above is from
the :443 VirtualHost, you just need to make sure that similar
configuration exists in the :80 VirtualHost configuration files.
> # initialize the SSL headers to a blank value to avoid http header
> forgeries RequestHeader set SSL_CLIENT_CERT "" RequestHeader set
> SSL_CIPHER "" RequestHeader set SSL_SESSION_ID "" RequestHeader set
> SSL_CIPHER_USEKEYSIZE ""
I'm not entirely sure:
a) How mod_nss expects to send the original HTTPS information to Tomcat
b) Whether or not Tomcat is configured to detect this information and
make sure it's available to the container/web application
c) In what order the "StdEnvVars" and "RequestHeader set" operations
take place.
I would want to make sure you've got all that right so tht the
following takes place:
1. Request comes in
2. Request has HTTPS-related headers stripped
3. Request has HTTPS-related headers added during proxying
You might consider using "RequestHeader unset" instead of
"RequestHeader set ''". There's no reason to send-over a blank string.
> RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
> RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader set
> SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set
> SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
If you are going to be "setting" each of these with new values, you
may as well not bother to "unset" (or "set" them to "") beforehand. I
think it's just extra processing that wastes time and doesn't
accomplish. Of course, you'll want to verify that I'm correct in that
it doesn't matter if you remove the "unsets" before the "sets", but I
think you'll be okay.
> ******* rewwrite.conf.testweb01 *******
>
> # # rewrite.conf: # These rules handle all http:// protocol
> requests. # RewriteEngine on
>
> # General: # Disable HTTP TRACE on all requests. RewriteCond
> %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
>
> # General: # Redirect requests to https, EXCEPT for the favicon,
> User-Defined URLs, System-Defined URLs, DDMS, AOP. # https rewrite
> rules are found in ssl.conf. RewriteCond %{SERVER_PROTOCOL}
> !https RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond
> %{REQUEST_URI} !^/mdr/ns RewriteCond %{REQUEST_URI}
> !^/mdr/irs RewriteCond %{REQUEST_URI} !^/mdr/documents
> RewriteCond %{REQUEST_URI} !^/dse/uriService RewriteCond
> %{REQUEST_URI} !^/dse/ns RewriteCond %{REQUEST_URI}
> !^/dse/irs RewriteCond %{REQUEST_URI} !^/dse/documents
> RewriteCond %{REQUEST_URI} !^/dse/downloads
>
> # query string containing wsdl (e.g. <somepath>/publish?wsdl), let
> it fetch as http RewriteCond %{QUERY_STRING} !wsdl
>
> RewriteRule ^/(.*)$ https://testweb01/$1
> <https://testweb01.novetta.com/$1> [last,redirect]
Oh, man. This is awful.
I'll bet the SSL-based configuration was re-written using
ProxyPass/ProxyPassReverse and then the mod_rewrite (that's what all
this stuff is) stuff was simply removed (or no longer referenced from
httpd.conf, probably).
But it looks like the RewriteCond/RewriteRule stuff was actually
enabling your proxying (in the very ugliest way possible, I might
add), so you lost your :80 proxying.
For the most part, you should be able to copy the <Location> sections
from your nss.conf into whatever file you would like to include to set
up your :80 VirtualHost, and that should be about it. (Of course,
you'll want to remove the NSSOptions and NSSVerifyClient sections as
well.)
If you'd prefer to have a slightly cleaner configuration, you can
change this:
> <Location /dse-help> #SSLRenegBufferSize 10486000 NSSVerifyClient
> none NSSOptions +StdEnvVars ProxyPass
> https://testapp01:8007/dse-help
> <https://testapp01.novetta.com:8007/dse-help> ProxyPassReverse
> https://testapp01:8007/dse-help
> <https://testapp01.novetta.com:8007/dse-help> </Location>
to this:
ProxyPass /dse-help https://testapp01:8007/dse-help
ProxyPassReverse /dse-help https://testapp01:8007/dse-help
, since you don't need additional configuration.
I would be willing to bet that if you set NSSOptions and
NSSVerifyClient at the top-level, you wouldn't have to specify it
separately in all of those <Location> sections, and your configuration
would get even simpler, but I'm not aware of all of the intricacies of
your environment, so I wouldn't recommend you make that change without
someone watching who knows this configuration very well.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVgHVRAAoJEBzwKT+lPKRYiGgP+gK5y4zid+1X4v3rKN2Se/Tv
seEbzhqW8IDigzysqUQAsqklmrNngyb4wbB6BltcPTVzwGiP3wHf1jKRfpXIdat8
KoXppXFgfL1FMP5HwfNBZhu8qQbv4bnbVPYRdvy5LsYtHIlZjD/BNMQRZKmiHQYk
cWYLMmqDs/oginqA1E9fDIrx1XZxSJBFL646S7dT3IQOUWxhgOtN3b5WDyZcY6bk
ZQMkgtALX1lyKDqWB8zVeqppQ9zljuF3dJno5q8E5bERYD98gTTEsnItuI7OeFSI
jkOtXG7IqmlOTd379q+A024oGubnwNmSeX2xMXwok03pd78okiCfTa46IyI407Se
eTyzProuCgks8EsDf5oUJflP9c8CVubyCkaI2cKR5APEiQNEqROdKy9IAlS1V2R0
Zo3mPQ5cq9S84DXPW5DtGdFTNvq7izZaOhRSg+oeUejpelWreVqS3BzkxGf2Kn9i
uutCCFF7k/OkrzCnUN8ASEEdXOibMJhhGlTjYaChZHmQLFAvocYNcUhUThtahCM+
LTGIm6thalOKzWEjv3L8OI0NV3F4pD6x6O1/TAMZU3Jq8zJjdiIBNEnOdeAWs/2M
uzFZA7f4BbpgiDMyM6+GnmHKeXIZwRFE6f94ucEAnwRSGjd/H03URHrig4cUvIK0
2IRJtDdgFtrOCIoX8OSD
=EQaf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
******* nss.conf.testweb01 *******
Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
NSSPassPhraseDialog file:/etc/httpd/.password.conf
#NSSPassPhraseDialog builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 10000
NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
<VirtualHost _default_:443>
DocumentRoot "/var/www/docroot"
NSSProxyCheckPeerCN Off
NSSEngine on
NSSProxyEngine on
NSSEnforceValidCerts off
NSSRenegotiation on
NSSRequireSafeNegotiation on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
NSSProxyCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
NSSProtocol TLSv1
NSSNickname Server-Cert
NSSCertificateDatabase /etc/httpd/alias
NSSFIPS on
NSSOCSP off
ProxyPreserveHost On
<Location /dse-help>
#SSLRenegBufferSize 10486000
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8007/dse-help
<https://testapp01.novetta.com:8007/dse-help>
ProxyPassReverse https://testapp01:8007/dse-help
<https://testapp01.novetta.com:8007/dse-help>
</Location>
<Location /dse/opensearch>
NSSOptions +ExportCertData +StdEnvVars
NSSVerifyClient require
ProxyPass https://testapp01:8007/dse/opensearch
<https://testapp01.novetta.com:8007/dse/opensearch>
ProxyPassReverse https://testapp01:8007/dse/opensearch
<https://testapp01.novetta.com:8007/dse/opensearch>
</Location>
<Location /dse/system_announcements/feed>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8007/dse/system_announcements/feed
<https://testapp01.novetta.com:8007/dse/system_announcements/feed>
ProxyPassReverse https://testapp01:8007/dse/system_announcements/feed
<https://testapp01.novetta.com:8007/dse/system_announcements/feed>
</Location>
<Location /dse/feeds>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8007/dse/feeds
<https://testapp01.novetta.com:8007/dse/feeds>
ProxyPassReverse https://testapp01:8007/dse/feeds
<https://testapp01.novetta.com:8007/dse/feeds>
</Location>
<Location /dse/web-services/publish?wsdl>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8007/dse/web-services/publish?wsdl
<https://testapp01.novetta.com:8007/dse/web-services/publish?wsdl>
ProxyPassReverse https://testapp01:8007/dse/web-services/publish?wsdl
<https://testapp01.novetta.com:8007/dse/web-services/publish?wsdl>
</Location>
<Location /dse/web-services/emtopic?wsdl>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8007/dse/web-services/emtopic?wsdl
<https://testapp01.novetta.com:8007/dse/web-services/emtopic?wsdl>
ProxyPassReverse https://testapp01:8007/dse/web-services/emtopic?wsdl
<https://testapp01.novetta.com:8007/dse/web-services/emtopic?wsdl>
</Location>
<Location /dse/web-services>
NSSOptions +ExportCertData +StdEnvVars
NSSVerifyClient require
ProxyPass https://testapp01:8007/dse/web-services
<https://testapp01.novetta.com:8007/dse/web-services>
ProxyPassReverse https://testapp01:8007/dse/web-services
<https://testapp01.novetta.com:8007/dse/web-services>
</Location>
<Location /dse>
#SSLRenegBufferSize 52430000
NSSVerifyClient optional
NSSOptions +ExportCertData +StdEnvVars
ProxyPass https://testapp01:8007/dse
<https://testapp01.novetta.com:8007/dse>
ProxyPassReverse https://testapp01:8007/dse
<https://testapp01.novetta.com:8007/dse>
</Location>
<Location /juddiv3/services/security?wsdl>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8009/juddiv3/services/security?wsdl
<https://testapp01.novetta.com:8009/juddiv3/services/security?wsdl>
ProxyPassReverse https://testapp01:8007/juddiv3/services/security?wsdl
<https://testapp01.novetta.com:8007/juddiv3/services/security?wsdl>
</Location>
<Location /juddiv3/services/inquiry?wsdl>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8009/juddiv3/services/inquiry?wsdl
<https://testapp01.novetta.com:8009/juddiv3/services/inquiry?wsdl>
ProxyPassReverse https://testapp01:8009/juddiv3/services/inquiry?wsdl
<https://testapp01.novetta.com:8009/juddiv3/services/inquiry?wsdl>
</Location>
<Location /juddiv3/services/publish?wsdl>
NSSVerifyClient none
NSSOptions +StdEnvVars
ProxyPass https://testapp01:8009/juddiv3/services/publish?wsdl
<https://testapp01.novetta.com:8009/juddiv3/services/publish?wsdl>
ProxyPassReverse https://testapp01:8009/juddiv3/services/publish?wsdl
<https://testapp01.novetta.com:8009/juddiv3/services/publish?wsdl>
</Location>
<Location /juddiv3>
#SSLRenegBufferSize 10486000
NSSVerifyClient require
NSSOptions +ExportCertData +StdEnvVars
ProxyPass https://testapp01:8009/juddiv3
<https://testapp01.novetta.com:8009/juddiv3>
ProxyPassReverse https://testapp01:8009/juddiv3
<https://testapp01.novetta.com:8009/juddiv3>
</Location>
<Location />
#SSLRenegBufferSize 52430000
NSSVerifyClient optional
NSSOptions +ExportCertData +StdEnvVars
ProxyPass https://testapp01:8007/dse
<https://testapp01.novetta.com:8007/dse>
ProxyPassReverse https://testapp01:8007/dse
<https://testapp01.novetta.com:8007/dse>
</Location>
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
NSSOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
NSSOptions +StdEnvVars
</Directory>
# initialize the SSL headers to a blank value to avoid http header forgeries
RequestHeader set SSL_CLIENT_CERT ""
RequestHeader set SSL_CIPHER ""
RequestHeader set SSL_SESSION_ID ""
RequestHeader set SSL_CIPHER_USEKEYSIZE ""
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s"
RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s"
RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x
%{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ErrorLog /etc/httpd/logs/error_log
TransferLog /etc/httpd/logs/access_log
LogLevel info
</VirtualHost>
******* rewwrite.conf.testweb01 *******
#
# rewrite.conf:
# These rules handle all http:// protocol requests.
#
RewriteEngine on
# General:
# Disable HTTP TRACE on all requests.
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
# General:
# Redirect requests to https, EXCEPT for the favicon, User-Defined URLs,
System-Defined URLs, DDMS, AOP.
# https rewrite rules are found in ssl.conf.
RewriteCond %{SERVER_PROTOCOL} !https
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/mdr/ns
RewriteCond %{REQUEST_URI} !^/mdr/irs
RewriteCond %{REQUEST_URI} !^/mdr/documents
RewriteCond %{REQUEST_URI} !^/dse/uriService
RewriteCond %{REQUEST_URI} !^/dse/ns
RewriteCond %{REQUEST_URI} !^/dse/irs
RewriteCond %{REQUEST_URI} !^/dse/documents
RewriteCond %{REQUEST_URI} !^/dse/downloads
# query string containing wsdl (e.g. <somepath>/publish?wsdl), let it fetch
as http
RewriteCond %{QUERY_STRING} !wsdl
RewriteRule ^/(.*)$ https://testweb01/$1
<https://testweb01.novetta.com/$1> [last,redirect]
# Redirect DSE 1.x URLs to new DSE 2.0 locations
RewriteRule ^/mdr/irs/(.*)$ http://testweb01/dse/irs/$1
<http://testweb01.novetta.com/dse/irs/$1> [L,redirect]
RewriteRule ^/mdr/ns/(.*)$ http://testweb01/dse/ns/$1
<http://testweb01.novetta.com/dse/ns/$1> [L,redirect]
RewriteRule ^/mdr/documents/(.*)$ http://testweb01/dse/documents/$1
<http://testweb01.novetta.com/dse/documents/$1> [L,redirect]
# Redirect / to the DSE Homepage.
RewriteRule ^/$ https://testweb01/dse <https://testweb01.novetta.com/dse>
[L]
******* ssl.conf.prodweb01 *******
#
# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailing information about
these
# directives see <URL:http://httpd.apache.org/docs-2.0/mod/mod_ssl.html>
#
# For the moment, see <URL:http://www.modssl.org/docs/> for this info.
# The documents are still being prepared from material donated by the
# modssl project.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# Until documentation is completed, please check http://www.modssl.org/
# for additional config examples and module docmentation. Directives
# and features of mod_ssl are largely unchanged from the mod_ssl project
# for Apache 1.3.
#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
# To allow connections to IPv6 addresses add "Listen [::]:443"
#
Listen 0.0.0.0:443
#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO
you
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
#
# Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
#SSLSessionCache none
#SSLSessionCache dbm:/var/cache/mod_ssl/scache(512000)
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex file:/var/log/httpd/ssl_mutex
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
#httpd 2.0.63 does not like SSLCryptoDevice
#SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
JkMountCopy On
#
# ssl.conf rewrite rules:
# These rules handle all https:// protocol requests.
#
RewriteEngine on
# Redirect DSE 1.x URLs to new DSE 2.0 locations
RewriteRule ^/mdr/mdwgDocuments.htm$
https://prodweb01/dse-help/en/Metadata_Working_Group
<https://prodweb01.novetta.com/dse-help/en/Metadata_Working_Group>
[L,redirect]
RewriteRule ^/eads(.*)$ https://prodweb01/dse
<https://prodweb01.novetta.com/dse> [L,redirect]
RewriteRule ^/mdr/details.htm(.*)$ https://prodweb01/dse/details$1
<https://prodweb01.novetta.com/dse/details$1> [L,redirect]
RewriteRule ^/mdr(.*)$ https://prodweb01/dse
<https://prodweb01.novetta.com/dse> [L,redirect]
RewriteRule ^/ncp(.*)$ https://prodweb01/dse
<https://prodweb01.novetta.com/dse> [L,redirect]
RewriteRule ^/sd(.*)$ https://prodweb01/dse
<https://prodweb01.novetta.com/dse> [L,redirect]
RewriteRule ^/dse/homepage.htm$ https://prodweb01/dse
<https://prodweb01.novetta.com/dse> [L,redirect]
# Redirect requests for OpenSearch
RewriteRule ^/opensearchdescription.xml$
https://prodweb01/dse/opensearch/opensearchdescription.xml
<https://prodweb01.novetta.com/dse/opensearch/opensearchdescription.xml>
[last,redirect]
RewriteRule ^/opensearch/$ https://prodweb01/dse/opensearch/$1
<https://prodweb01.novetta.com/dse/opensearch/$1> [last,redirect]
# Redirect requests for UDDI
RewriteRule ^/security(.*)$ https://prodweb01/juddiv3/services/security$1
<https://prodweb01.novetta.com/juddiv3/services/security$1> [last,redirect]
RewriteRule ^/inquiry(.*)$ https://prodweb01/juddiv3/services/inquiry
<https://prodweb01.novetta.com/juddiv3/services/inquiry> [L,redirect]
RewriteRule ^/publish(.*)$ https://prodweb01/juddiv3/services/publish
<https://prodweb01.novetta.com/juddiv3/services/publish> [L,redirect]
RewriteRule ^/subscription(.*)$
https://prodweb01/juddiv3/services/subscription
<https://prodweb01.novetta.com/juddiv3/services/subscription> [L,redirect]
# Redirect / to the DSE Homepage.
RewriteRule ^/$ https://prodweb01/dse <https://prodweb01.novetta.com/dse>
[last,redirect]
# General setup for the virtual host; inherited from global configuration.
# DocumentRoot "/var/www/html"
# ServerAdmin you@your.address
# ServerName new.host.name:443
# Use separate log files:
ErrorLog "|/usr/sbin/rotatelogs /var/log/httpd/ssl_error_log.%Y%m%d 86400
-300"
LogFormat "%h %{JSESSIONID}C %{SSL_CLIENT_S_DN_CN}e %t \"%r\" %>s %b %D"
TransferLog "|/usr/sbin/rotatelogs /var/log/httpd/ssl_access_log.%Y%m%d
86400 -300"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
#SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLProtocol TLSv1
SSLCipherSuite AES256-SHA:AES128-SHA:DES-CBC3-SHA
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with `make certificate' under
# built time. Keep in mind that if you've both a RSA and a DSA
# certificate you can configure both in parallel (to also allow
# the use of DSA ciphers, etc.)
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/httpd/conf/ssl.crt/ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/httpd/conf/ssl.crt
SSLCACertificateFile /etc/httpd/conf/ssl.crt/dse-trusted.crt
SSLCADNRequestFile /etc/httpd/conf/ssl.crt/browser-accepting.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/httpd/conf/ssl.crl
#SSLCARevocationFile /etc/httpd/conf/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
SSLVerifyClient none
SSLInsecureRenegotiation on
<Location /juddiv3>
SSLVerifyClient require
SSLVerifyDepth 5
SSLRenegBufferSize 10486000
</Location>
<Location /juddiv3/>
SSLVerifyClient require
SSLVerifyDepth 5
SSLRenegBufferSize 10486000
</Location>
<Location /dse>
SSLVerifyClient optional
SSLVerifyDepth 5
SSLRenegBufferSize 52430000
</Location>
<Location /dse/>
SSLVerifyClient optional
SSLVerifyDepth 5
SSLRenegBufferSize 52430000
</Location>
<Location /dse-help>
SSLVerifyClient none
SSLVerifyDepth 5
SSLRenegBufferSize 10486000
</Location>
<Location /dse-help/>
SSLVerifyClient none
SSLVerifyDepth 5
SSLRenegBufferSize 10486000
</Location>
<Location /dse/opensearch>
SSLVerifyClient require
SSLVerifyDepth 5
</Location>
<Location /dse/opensearch/>
SSLVerifyClient require
SSLVerifyDepth 5
</Location>
<Location /dse/web-services>
SSLVerifyClient require
SSLVerifyDepth 5
</Location>
<Location /dse/web-services/>
SSLVerifyClient require
SSLVerifyDepth 5
</Location>
<Location /dse/system_announcements/feed>
SSLVerifyClient none
</Location>
<Location /dse/feeds>
SSLVerifyClient none
</Location>
<Location /dse/web-services/publish?wsdl>
SSLVerifyClient none
</Location>
<Location /dse/web-services/emtopic?wsdl>
SSLVerifyClient none
</Location>
<Location /dse/web-services/juddiv3/services/security?wsdl>
SSLVerifyClient none
</Location>
<Location /dse/web-services/juddiv3/services/inquiry?wsdl>
SSLVerifyClient none
</Location>
<Location /dse/web-services/juddiv3/services/publish?wsdl>
SSLVerifyClient none
</Location>
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means
that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the
user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment
variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
SSLOptions +ExportCertData +StdEnvVars
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait
for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach
where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers.
Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
******* rewrite.conf.prodweb01 *******
#
# rewrite.conf:
# These rules handle all http:// protocol requests.
#
RewriteEngine on
# General:
# Disable HTTP TRACE on all requests.
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
# General:
# Redirect requests to https, EXCEPT for the favicon, User-Defined URLs,
System-Defined URLs, DDMS, AOP.
# https rewrite rules are found in ssl.conf.
RewriteCond %{SERVER_PROTOCOL} !https
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/mdr/ns
RewriteCond %{REQUEST_URI} !^/mdr/irs
RewriteCond %{REQUEST_URI} !^/mdr/documents
RewriteCond %{REQUEST_URI} !^/dse/ns
RewriteCond %{REQUEST_URI} !^/dse/irs
RewriteCond %{REQUEST_URI} !^/dse/documents
# query string containing wsdl (e.g. <somepath>/publish?wsdl), let it fetch
as http
RewriteCond %{QUERY_STRING} !wsdl
RewriteRule ^/(.*)$ https://prodweb01/$1 [last,redirect]
# Redirect DSE 1.x URLs to new DSE 2.0 locations
RewriteRule ^/mdr/irs/(.*)$ http://prodweb01/dse/irs/$1 [L,redirect]
RewriteRule ^/mdr/ns/(.*)$ http://prodweb01/dse/ns/$1 [L,redirect]
RewriteRule ^/mdr/documents/(.*)$ http://prodweb01/dse/documents/$1
[L,redirect]
# Redirect / to the DSE Homepage.
RewriteRule ^/$ https://prodweb01/dse [L]
On Tue, Jun 16, 2015 at 2:10 PM, Cohen, Laurence <lc...@novetta.com> wrote:
> Yeah, I'm going to have to figure this out. If I paste the text in the
> email it will be very long.
>
> On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>>
>>
>> Am 16. Juni 2015 19:54:40 MESZ, schrieb "Cohen, Laurence" <
>> lcohen@novetta.com>:
>> >On the old instance, represented in these files by prodweb01, ssl.conf
>> >and
>> >rewrite.conf were included from httpd.conf
>> >
>> >On the new instance represented by testweb01, nss.conf and rewrite.conf
>> >are
>> >included from httpd.conf, and ssl.conf is no longer used. You'll see
>> >that
>> >there was an attempt to move all of the RewriteRules from the ssl.conf
>> >in
>> >the old instance to ProxyPass statements in nss.conf. I'm assuming you
>> >are
>> >correct that something is not correct with these rules.
>>
>> Did you attach files to your mail? The mailing list strips most
>> attachments. You might be lucky attaching text files.
>>
>> Or you could strip out any comments and paste them inline. Our you put
>> them somewhere else and send a link to the files.
>>
>> Regards,
>> Felix
>>
>> >
>> >Thanks,
>> >
>> >Larry Cohen
>> >
>> >On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence <lc...@novetta.com>
>> >wrote:
>> >
>> >> I am most definitely confused. :-)
>> >>
>> >> I'm gathering and sanitizing configuration files now.
>> >>
>> >> Thanks,
>> >>
>> >> Larry
>> >>
>> >> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
>> >> chris@christopherschultz.net> wrote:
>> >>
>> >>> -----BEGIN PGP SIGNED MESSAGE-----
>> >>> Hash: SHA256
>> >>>
>> >>> Laurence,
>> >>>
>> >>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
>> >>> > Thanks for everyone's response. to Andre' Warnier, yes. There
>> >are
>> >>> > many ProxyPass statements in nss.conf on the Apache webserver.
>> >>> > They appear to have taken the place of redirect statements in
>> >>> > ssl.conf, which is no longer in use.
>> >>>
>> >>> I think you may be confused. mod_nss looks like a replacement for
>> >>> mod_ssl, which means it's only being used for connections coming
>> >>> *into* the Apache httpd process -- probably from clients.
>> >>>
>> >>> Yes, mod_ssl is also used to handle HTTPS going *out* through
>> >>> mod_proxy, but you say that's working, right?
>> >>>
>> >>> mod_ssl doesn't have any "redirect" configuration. If you had
>> >>> "Redirect [something]" then it was using mod_alias, and that has
>> >>> nothing to do with either mod_nss (nee mod_ssl) or whatever module
>> >you
>> >>> are using to proxy from httpd to Tomcat (probably mod_proxy_http).
>> >>>
>> >>> > Your configuration assumption is correct, except that the users
>> >>> > will connect to the webserver on port 80 and port 443, and it is
>> >>> > invisible to them where they are going on the app server.
>> >>>
>> >>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
>> >>> able to in the past, then you should have to change nothing in your
>> >>> configuration.
>> >>>
>> >>> My guess is that your ProxyPass directives for the :80 VirtualHost
>> >>> were somehow damaged in the switch-over.
>> >>>
>> >>> Can you show us the :443 configuration versus the :80 configuration
>> >in
>> >>> terms of ProxyPass and ProxyPassReverse directives?
>> >>>
>> >>> - -chris
>> >>> -----BEGIN PGP SIGNATURE-----
>> >>> Comment: GPGTools - http://gpgtools.org
>> >>>
>> >>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
>> >>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
>> >>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
>> >>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
>> >>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
>> >>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
>> >>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
>> >>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
>> >>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
>> >>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
>> >>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
>> >>> RpQ2KXVnBjLHYdoFGpSD
>> >>> =YmrV
>> >>> -----END PGP SIGNATURE-----
>> >>>
>> >>>
>> >---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >>> For additional commands, e-mail: users-help@tomcat.apache.org
>> >>>
>> >>>
>> >>
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: [OT] Brand new to Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chuck,
On 6/16/15 2:39 PM, Caldarale, Charles R wrote:
>> From: Cohen, Laurence [mailto:lcohen@novetta.com] Subject: Re:
>> Brand new to Tomcat
>
>> Sorry, I sent that last post before I sent this one. I'm
>> assuming this is what you were meaning about top posting? I
>> should just post after all previous posts?
>
> Yes, but trimming out the fluff (e.g., footers and any
> corporate-required disclaimers) while you're at it is also
> desirable.
Yeah, I hate all those corporate disclaimers.
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the
> sender and delete the e-mail and its attachments from all
> computers.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVgHIWAAoJEBzwKT+lPKRYcDgP/2nWkIEG17cGajqqtJMht9XO
8u2+4zBTK92ehKfzJ0wO7gLIpRene6hpJ3jatLQEyo5vfpxsKHkW38t7hojjJveD
QX06FGrjNt5o0U6H2oPufaxaix1P92pSZMv2UD6TH/2/XFkm1tsw3sGUaoRlo7CH
pNF1gCfwpk7daxq9uuE6fE2jxWyX0GsBVaKrtqj/aM8pP7lpUd2XvTsDXme9F44w
TtTWESJ3uUK4shAu3tr0nJpdgs8UjC3my7QREKdOB1776jF3kKbtBLyjp0PZ12fS
8LhDAaibjztS740HVu5rjs5XGuRXuHIaOF2YlG7XFU/IwUf/MRYwGAxqTA8sNdAa
Tr1DvaOU6H+9/YMXHQg8Jof6yThhvcMu4MfYy2ylGHirds4ciEf+QYv5I5F8xYJW
SQoHC16WPM+7PFpdyQ9b+/CNRMTZO8Gg+X/Urb82/YEK2gPDdBW1ZlBTVgszk3pd
IFjS3BmnK5VlKiEhfaZGmtcw5fNFbaRtsNBniHMDn1PLSi6FzcwcTp+Eurk7DOu7
9fy8TouE2tpYY0mR6l/tDlPH4j9shp58tAyRpXdBjj0RFlWQZ6HbEJ2QMfUpof+M
1A1c6Ytt8SZ5hMD90KmjYIP9j+oXbeJTg7uPdmXxKAVJjS3dX6lj/P+DVBW5gvGk
6Ez86RT8BR9bC+9qkvNH
=XHit
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Brand new to Tomcat
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Cohen, Laurence [mailto:lcohen@novetta.com]
> Subject: Re: Brand new to Tomcat
> I apologize everyone.
No apology needed - you're doing much better than many.
> Are there some instructions that I'm supposed to have read through. I'd be happy to
> review anything that will provide direction so I can be a good community member.
The mailing list rules/guidelines are here:
http://tomcat.apache.org/lists.html#tomcat-users
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
On Tue, Jun 16, 2015 at 2:39 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Cohen, Laurence [mailto:lcohen@novetta.com]
> > Subject: Re: Brand new to Tomcat
>
> > Sorry, I sent that last post before I sent this one. I'm assuming this
> is
> > what you were meaning about top posting? I should just post after all
> > previous posts?
>
> Yes, but trimming out the fluff (e.g., footers and any corporate-required
> disclaimers) while you're at it is also desirable.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
I apologize everyone. Are there some instructions that I'm supposed to
have read through. I'd be happy to review anything that will provide
direction so I can be a good community member.
Thanks,
Larry
RE: Brand new to Tomcat
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Cohen, Laurence [mailto:lcohen@novetta.com]
> Subject: Re: Brand new to Tomcat
> Sorry, I sent that last post before I sent this one. I'm assuming this is
> what you were meaning about top posting? I should just post after all
> previous posts?
Yes, but trimming out the fluff (e.g., footers and any corporate-required disclaimers) while you're at it is also desirable.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
On Tue, Jun 16, 2015 at 2:26 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
>
>
> Am 16. Juni 2015 20:10:52 MESZ, schrieb "Cohen, Laurence" <
> lcohen@novetta.com>:
> >Yeah, I'm going to have to figure this out. If I paste the text in the
> >email it will be very long.
>
> Maybe you could look for the changes yourself (diff might be your friend)
> and just paste the things that are different.
>
> In the SuSE package is a perl script, which claims to do the conversion
> from mod_ssl to mod_nss. You could try that on your original config files.
>
> By the way. It is considered bad style to top post in replies.
>
> Regards,
> Felix
> >
> >On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher <
> >felix.schumacher@internetallee.de> wrote:
> >
> >>
> >>
> >> Am 16. Juni 2015 19:54:40 MESZ, schrieb "Cohen, Laurence" <
> >> lcohen@novetta.com>:
> >> >On the old instance, represented in these files by prodweb01,
> >ssl.conf
> >> >and
> >> >rewrite.conf were included from httpd.conf
> >> >
> >> >On the new instance represented by testweb01, nss.conf and
> >rewrite.conf
> >> >are
> >> >included from httpd.conf, and ssl.conf is no longer used. You'll
> >see
> >> >that
> >> >there was an attempt to move all of the RewriteRules from the
> >ssl.conf
> >> >in
> >> >the old instance to ProxyPass statements in nss.conf. I'm assuming
> >you
> >> >are
> >> >correct that something is not correct with these rules.
> >>
> >> Did you attach files to your mail? The mailing list strips most
> >> attachments. You might be lucky attaching text files.
> >>
> >> Or you could strip out any comments and paste them inline. Our you
> >put
> >> them somewhere else and send a link to the files.
> >>
> >> Regards,
> >> Felix
> >>
> >> >
> >> >Thanks,
> >> >
> >> >Larry Cohen
> >> >
> >> >On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence
> ><lc...@novetta.com>
> >> >wrote:
> >> >
> >> >> I am most definitely confused. :-)
> >> >>
> >> >> I'm gathering and sanitizing configuration files now.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Larry
> >> >>
> >> >> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
> >> >> chris@christopherschultz.net> wrote:
> >> >>
> >> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >> >>> Hash: SHA256
> >> >>>
> >> >>> Laurence,
> >> >>>
> >> >>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
> >> >>> > Thanks for everyone's response. to Andre' Warnier, yes. There
> >> >are
> >> >>> > many ProxyPass statements in nss.conf on the Apache webserver.
> >> >>> > They appear to have taken the place of redirect statements in
> >> >>> > ssl.conf, which is no longer in use.
> >> >>>
> >> >>> I think you may be confused. mod_nss looks like a replacement for
> >> >>> mod_ssl, which means it's only being used for connections coming
> >> >>> *into* the Apache httpd process -- probably from clients.
> >> >>>
> >> >>> Yes, mod_ssl is also used to handle HTTPS going *out* through
> >> >>> mod_proxy, but you say that's working, right?
> >> >>>
> >> >>> mod_ssl doesn't have any "redirect" configuration. If you had
> >> >>> "Redirect [something]" then it was using mod_alias, and that has
> >> >>> nothing to do with either mod_nss (nee mod_ssl) or whatever
> >module
> >> >you
> >> >>> are using to proxy from httpd to Tomcat (probably
> >mod_proxy_http).
> >> >>>
> >> >>> > Your configuration assumption is correct, except that the users
> >> >>> > will connect to the webserver on port 80 and port 443, and it
> >is
> >> >>> > invisible to them where they are going on the app server.
> >> >>>
> >> >>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl
> >was
> >> >>> able to in the past, then you should have to change nothing in
> >your
> >> >>> configuration.
> >> >>>
> >> >>> My guess is that your ProxyPass directives for the :80
> >VirtualHost
> >> >>> were somehow damaged in the switch-over.
> >> >>>
> >> >>> Can you show us the :443 configuration versus the :80
> >configuration
> >> >in
> >> >>> terms of ProxyPass and ProxyPassReverse directives?
> >> >>>
> >> >>> - -chris
> >> >>> -----BEGIN PGP SIGNATURE-----
> >> >>> Comment: GPGTools - http://gpgtools.org
> >> >>>
> >> >>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
> >> >>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
> >> >>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
> >> >>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
> >> >>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
> >> >>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
> >> >>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
> >> >>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
> >> >>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
> >> >>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
> >> >>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
> >> >>> RpQ2KXVnBjLHYdoFGpSD
> >> >>> =YmrV
> >> >>> -----END PGP SIGNATURE-----
> >> >>>
> >> >>>
> >>
> >>---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >>------------------------------------------------------------------------
> >> >
> >> >
> >>
> >>---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> >For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Sorry, I sent that last post before I sent this one. I'm assuming this is
what you were meaning about top posting? I should just post after all
previous posts?
The problem with doing a diff is that the RewriteRules and ProxyPass rules
are in a different format obviously, so I'd probably need to walk through
them one by one. I will attempt to do that though.
Thanks,
Larry Cohen
Re: Brand new to Tomcat
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 16. Juni 2015 20:10:52 MESZ, schrieb "Cohen, Laurence" <lc...@novetta.com>:
>Yeah, I'm going to have to figure this out. If I paste the text in the
>email it will be very long.
Maybe you could look for the changes yourself (diff might be your friend) and just paste the things that are different.
In the SuSE package is a perl script, which claims to do the conversion from mod_ssl to mod_nss. You could try that on your original config files.
By the way. It is considered bad style to top post in replies.
Regards,
Felix
>
>On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher <
>felix.schumacher@internetallee.de> wrote:
>
>>
>>
>> Am 16. Juni 2015 19:54:40 MESZ, schrieb "Cohen, Laurence" <
>> lcohen@novetta.com>:
>> >On the old instance, represented in these files by prodweb01,
>ssl.conf
>> >and
>> >rewrite.conf were included from httpd.conf
>> >
>> >On the new instance represented by testweb01, nss.conf and
>rewrite.conf
>> >are
>> >included from httpd.conf, and ssl.conf is no longer used. You'll
>see
>> >that
>> >there was an attempt to move all of the RewriteRules from the
>ssl.conf
>> >in
>> >the old instance to ProxyPass statements in nss.conf. I'm assuming
>you
>> >are
>> >correct that something is not correct with these rules.
>>
>> Did you attach files to your mail? The mailing list strips most
>> attachments. You might be lucky attaching text files.
>>
>> Or you could strip out any comments and paste them inline. Our you
>put
>> them somewhere else and send a link to the files.
>>
>> Regards,
>> Felix
>>
>> >
>> >Thanks,
>> >
>> >Larry Cohen
>> >
>> >On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence
><lc...@novetta.com>
>> >wrote:
>> >
>> >> I am most definitely confused. :-)
>> >>
>> >> I'm gathering and sanitizing configuration files now.
>> >>
>> >> Thanks,
>> >>
>> >> Larry
>> >>
>> >> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
>> >> chris@christopherschultz.net> wrote:
>> >>
>> >>> -----BEGIN PGP SIGNED MESSAGE-----
>> >>> Hash: SHA256
>> >>>
>> >>> Laurence,
>> >>>
>> >>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
>> >>> > Thanks for everyone's response. to Andre' Warnier, yes. There
>> >are
>> >>> > many ProxyPass statements in nss.conf on the Apache webserver.
>> >>> > They appear to have taken the place of redirect statements in
>> >>> > ssl.conf, which is no longer in use.
>> >>>
>> >>> I think you may be confused. mod_nss looks like a replacement for
>> >>> mod_ssl, which means it's only being used for connections coming
>> >>> *into* the Apache httpd process -- probably from clients.
>> >>>
>> >>> Yes, mod_ssl is also used to handle HTTPS going *out* through
>> >>> mod_proxy, but you say that's working, right?
>> >>>
>> >>> mod_ssl doesn't have any "redirect" configuration. If you had
>> >>> "Redirect [something]" then it was using mod_alias, and that has
>> >>> nothing to do with either mod_nss (nee mod_ssl) or whatever
>module
>> >you
>> >>> are using to proxy from httpd to Tomcat (probably
>mod_proxy_http).
>> >>>
>> >>> > Your configuration assumption is correct, except that the users
>> >>> > will connect to the webserver on port 80 and port 443, and it
>is
>> >>> > invisible to them where they are going on the app server.
>> >>>
>> >>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl
>was
>> >>> able to in the past, then you should have to change nothing in
>your
>> >>> configuration.
>> >>>
>> >>> My guess is that your ProxyPass directives for the :80
>VirtualHost
>> >>> were somehow damaged in the switch-over.
>> >>>
>> >>> Can you show us the :443 configuration versus the :80
>configuration
>> >in
>> >>> terms of ProxyPass and ProxyPassReverse directives?
>> >>>
>> >>> - -chris
>> >>> -----BEGIN PGP SIGNATURE-----
>> >>> Comment: GPGTools - http://gpgtools.org
>> >>>
>> >>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
>> >>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
>> >>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
>> >>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
>> >>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
>> >>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
>> >>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
>> >>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
>> >>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
>> >>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
>> >>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
>> >>> RpQ2KXVnBjLHYdoFGpSD
>> >>> =YmrV
>> >>> -----END PGP SIGNATURE-----
>> >>>
>> >>>
>>
>>---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >>> For additional commands, e-mail: users-help@tomcat.apache.org
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>------------------------------------------------------------------------
>> >
>> >
>>
>>---------------------------------------------------------------------
>> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
Yeah, I'm going to have to figure this out. If I paste the text in the
email it will be very long.
On Tue, Jun 16, 2015 at 2:00 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
>
>
> Am 16. Juni 2015 19:54:40 MESZ, schrieb "Cohen, Laurence" <
> lcohen@novetta.com>:
> >On the old instance, represented in these files by prodweb01, ssl.conf
> >and
> >rewrite.conf were included from httpd.conf
> >
> >On the new instance represented by testweb01, nss.conf and rewrite.conf
> >are
> >included from httpd.conf, and ssl.conf is no longer used. You'll see
> >that
> >there was an attempt to move all of the RewriteRules from the ssl.conf
> >in
> >the old instance to ProxyPass statements in nss.conf. I'm assuming you
> >are
> >correct that something is not correct with these rules.
>
> Did you attach files to your mail? The mailing list strips most
> attachments. You might be lucky attaching text files.
>
> Or you could strip out any comments and paste them inline. Our you put
> them somewhere else and send a link to the files.
>
> Regards,
> Felix
>
> >
> >Thanks,
> >
> >Larry Cohen
> >
> >On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence <lc...@novetta.com>
> >wrote:
> >
> >> I am most definitely confused. :-)
> >>
> >> I'm gathering and sanitizing configuration files now.
> >>
> >> Thanks,
> >>
> >> Larry
> >>
> >> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
> >> chris@christopherschultz.net> wrote:
> >>
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA256
> >>>
> >>> Laurence,
> >>>
> >>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
> >>> > Thanks for everyone's response. to Andre' Warnier, yes. There
> >are
> >>> > many ProxyPass statements in nss.conf on the Apache webserver.
> >>> > They appear to have taken the place of redirect statements in
> >>> > ssl.conf, which is no longer in use.
> >>>
> >>> I think you may be confused. mod_nss looks like a replacement for
> >>> mod_ssl, which means it's only being used for connections coming
> >>> *into* the Apache httpd process -- probably from clients.
> >>>
> >>> Yes, mod_ssl is also used to handle HTTPS going *out* through
> >>> mod_proxy, but you say that's working, right?
> >>>
> >>> mod_ssl doesn't have any "redirect" configuration. If you had
> >>> "Redirect [something]" then it was using mod_alias, and that has
> >>> nothing to do with either mod_nss (nee mod_ssl) or whatever module
> >you
> >>> are using to proxy from httpd to Tomcat (probably mod_proxy_http).
> >>>
> >>> > Your configuration assumption is correct, except that the users
> >>> > will connect to the webserver on port 80 and port 443, and it is
> >>> > invisible to them where they are going on the app server.
> >>>
> >>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
> >>> able to in the past, then you should have to change nothing in your
> >>> configuration.
> >>>
> >>> My guess is that your ProxyPass directives for the :80 VirtualHost
> >>> were somehow damaged in the switch-over.
> >>>
> >>> Can you show us the :443 configuration versus the :80 configuration
> >in
> >>> terms of ProxyPass and ProxyPassReverse directives?
> >>>
> >>> - -chris
> >>> -----BEGIN PGP SIGNATURE-----
> >>> Comment: GPGTools - http://gpgtools.org
> >>>
> >>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
> >>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
> >>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
> >>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
> >>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
> >>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
> >>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
> >>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
> >>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
> >>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
> >>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
> >>> RpQ2KXVnBjLHYdoFGpSD
> >>> =YmrV
> >>> -----END PGP SIGNATURE-----
> >>>
> >>>
> >---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Brand new to Tomcat
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 16. Juni 2015 19:54:40 MESZ, schrieb "Cohen, Laurence" <lc...@novetta.com>:
>On the old instance, represented in these files by prodweb01, ssl.conf
>and
>rewrite.conf were included from httpd.conf
>
>On the new instance represented by testweb01, nss.conf and rewrite.conf
>are
>included from httpd.conf, and ssl.conf is no longer used. You'll see
>that
>there was an attempt to move all of the RewriteRules from the ssl.conf
>in
>the old instance to ProxyPass statements in nss.conf. I'm assuming you
>are
>correct that something is not correct with these rules.
Did you attach files to your mail? The mailing list strips most attachments. You might be lucky attaching text files.
Or you could strip out any comments and paste them inline. Our you put them somewhere else and send a link to the files.
Regards,
Felix
>
>Thanks,
>
>Larry Cohen
>
>On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence <lc...@novetta.com>
>wrote:
>
>> I am most definitely confused. :-)
>>
>> I'm gathering and sanitizing configuration files now.
>>
>> Thanks,
>>
>> Larry
>>
>> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Laurence,
>>>
>>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
>>> > Thanks for everyone's response. to Andre' Warnier, yes. There
>are
>>> > many ProxyPass statements in nss.conf on the Apache webserver.
>>> > They appear to have taken the place of redirect statements in
>>> > ssl.conf, which is no longer in use.
>>>
>>> I think you may be confused. mod_nss looks like a replacement for
>>> mod_ssl, which means it's only being used for connections coming
>>> *into* the Apache httpd process -- probably from clients.
>>>
>>> Yes, mod_ssl is also used to handle HTTPS going *out* through
>>> mod_proxy, but you say that's working, right?
>>>
>>> mod_ssl doesn't have any "redirect" configuration. If you had
>>> "Redirect [something]" then it was using mod_alias, and that has
>>> nothing to do with either mod_nss (nee mod_ssl) or whatever module
>you
>>> are using to proxy from httpd to Tomcat (probably mod_proxy_http).
>>>
>>> > Your configuration assumption is correct, except that the users
>>> > will connect to the webserver on port 80 and port 443, and it is
>>> > invisible to them where they are going on the app server.
>>>
>>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
>>> able to in the past, then you should have to change nothing in your
>>> configuration.
>>>
>>> My guess is that your ProxyPass directives for the :80 VirtualHost
>>> were somehow damaged in the switch-over.
>>>
>>> Can you show us the :443 configuration versus the :80 configuration
>in
>>> terms of ProxyPass and ProxyPassReverse directives?
>>>
>>> - -chris
>>> -----BEGIN PGP SIGNATURE-----
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
>>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
>>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
>>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
>>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
>>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
>>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
>>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
>>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
>>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
>>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
>>> RpQ2KXVnBjLHYdoFGpSD
>>> =YmrV
>>> -----END PGP SIGNATURE-----
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
>
>------------------------------------------------------------------------
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
On the old instance, represented in these files by prodweb01, ssl.conf and
rewrite.conf were included from httpd.conf
On the new instance represented by testweb01, nss.conf and rewrite.conf are
included from httpd.conf, and ssl.conf is no longer used. You'll see that
there was an attempt to move all of the RewriteRules from the ssl.conf in
the old instance to ProxyPass statements in nss.conf. I'm assuming you are
correct that something is not correct with these rules.
Thanks,
Larry Cohen
On Tue, Jun 16, 2015 at 1:36 PM, Cohen, Laurence <lc...@novetta.com> wrote:
> I am most definitely confused. :-)
>
> I'm gathering and sanitizing configuration files now.
>
> Thanks,
>
> Larry
>
> On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Laurence,
>>
>> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
>> > Thanks for everyone's response. to Andre' Warnier, yes. There are
>> > many ProxyPass statements in nss.conf on the Apache webserver.
>> > They appear to have taken the place of redirect statements in
>> > ssl.conf, which is no longer in use.
>>
>> I think you may be confused. mod_nss looks like a replacement for
>> mod_ssl, which means it's only being used for connections coming
>> *into* the Apache httpd process -- probably from clients.
>>
>> Yes, mod_ssl is also used to handle HTTPS going *out* through
>> mod_proxy, but you say that's working, right?
>>
>> mod_ssl doesn't have any "redirect" configuration. If you had
>> "Redirect [something]" then it was using mod_alias, and that has
>> nothing to do with either mod_nss (nee mod_ssl) or whatever module you
>> are using to proxy from httpd to Tomcat (probably mod_proxy_http).
>>
>> > Your configuration assumption is correct, except that the users
>> > will connect to the webserver on port 80 and port 443, and it is
>> > invisible to them where they are going on the app server.
>>
>> Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
>> able to in the past, then you should have to change nothing in your
>> configuration.
>>
>> My guess is that your ProxyPass directives for the :80 VirtualHost
>> were somehow damaged in the switch-over.
>>
>> Can you show us the :443 configuration versus the :80 configuration in
>> terms of ProxyPass and ProxyPassReverse directives?
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
>> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
>> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
>> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
>> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
>> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
>> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
>> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
>> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
>> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
>> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
>> RpQ2KXVnBjLHYdoFGpSD
>> =YmrV
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
I am most definitely confused. :-)
I'm gathering and sanitizing configuration files now.
Thanks,
Larry
On Tue, Jun 16, 2015 at 1:26 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Laurence,
>
> On 6/16/15 1:02 PM, Cohen, Laurence wrote:
> > Thanks for everyone's response. to Andre' Warnier, yes. There are
> > many ProxyPass statements in nss.conf on the Apache webserver.
> > They appear to have taken the place of redirect statements in
> > ssl.conf, which is no longer in use.
>
> I think you may be confused. mod_nss looks like a replacement for
> mod_ssl, which means it's only being used for connections coming
> *into* the Apache httpd process -- probably from clients.
>
> Yes, mod_ssl is also used to handle HTTPS going *out* through
> mod_proxy, but you say that's working, right?
>
> mod_ssl doesn't have any "redirect" configuration. If you had
> "Redirect [something]" then it was using mod_alias, and that has
> nothing to do with either mod_nss (nee mod_ssl) or whatever module you
> are using to proxy from httpd to Tomcat (probably mod_proxy_http).
>
> > Your configuration assumption is correct, except that the users
> > will connect to the webserver on port 80 and port 443, and it is
> > invisible to them where they are going on the app server.
>
> Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
> able to in the past, then you should have to change nothing in your
> configuration.
>
> My guess is that your ProxyPass directives for the :80 VirtualHost
> were somehow damaged in the switch-over.
>
> Can you show us the :443 configuration versus the :80 configuration in
> terms of ProxyPass and ProxyPassReverse directives?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
> 4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
> exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
> rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
> yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
> FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
> zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
> +XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
> zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
> CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
> mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
> RpQ2KXVnBjLHYdoFGpSD
> =YmrV
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Brand new to Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Laurence,
On 6/16/15 1:02 PM, Cohen, Laurence wrote:
> Thanks for everyone's response. to Andre' Warnier, yes. There are
> many ProxyPass statements in nss.conf on the Apache webserver.
> They appear to have taken the place of redirect statements in
> ssl.conf, which is no longer in use.
I think you may be confused. mod_nss looks like a replacement for
mod_ssl, which means it's only being used for connections coming
*into* the Apache httpd process -- probably from clients.
Yes, mod_ssl is also used to handle HTTPS going *out* through
mod_proxy, but you say that's working, right?
mod_ssl doesn't have any "redirect" configuration. If you had
"Redirect [something]" then it was using mod_alias, and that has
nothing to do with either mod_nss (nee mod_ssl) or whatever module you
are using to proxy from httpd to Tomcat (probably mod_proxy_http).
> Your configuration assumption is correct, except that the users
> will connect to the webserver on port 80 and port 443, and it is
> invisible to them where they are going on the app server.
Assuming that mod_nss can service mod_proxy_http just as mod_ssl was
able to in the past, then you should have to change nothing in your
configuration.
My guess is that your ProxyPass directives for the :80 VirtualHost
were somehow damaged in the switch-over.
Can you show us the :443 configuration versus the :80 configuration in
terms of ProxyPass and ProxyPassReverse directives?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVgFwtAAoJEBzwKT+lPKRYuU8P/Ao9G5qfkl3b/vWgG4rP2ooW
4rN+I7L7p3aNGp5GXylfPh04B7R3+Lc0OS82lZvRlDP0UWCEBChA4j+JIBddIqXG
exiOHS7lZLEpduZuWr0cK3/DpcA1KcF9xQYjji2SdxfyiYiZPY7WepXd/Fm6gs0a
rp7f8WpGl5onhDRz0KKGmZK0YJbhMr8JwlrdeKolUlpeG8s9pmFiccQgN+QVhmJL
yv6sGcrxoBBZAnG+1MbUzHAh2SXvjaBVXessf5L/w8ttCXWb3a6KcuZp+RJwTLZ9
FYO+DPlfGIP5FM9+8YL8CtF39D0SGM+4Uz93hHJr37eVVRmSxVj7zDgnT3OdGfe1
zjanRi4abrrMeXWQG1KsUgqS8u5iq/+FC9s6+i5iSt6cRRQQHwWH5337U85s3SPB
+XrjXdbLpdTe6pZz2AJ9htXOwO/o0b0sO7vVls9r4F7gSPbnnETyk/jWjcVbRClb
zPPR2rF4/XNDy3mCmid2dMoIpk2IrTxTt1tP9gPf0ZNl0JFeWSZrpY8EJhd5lyZs
CGJDKBph3BLgfmHV5yj/lZXwqW63RTuWluVfliVnDo7LEkTMa424yTaF68XBpRWL
mic2/HKVvrqn9CypeOhrJ9SmDer/xJ8lZWUP5DMijuYJaTbgDcCQEIcj2pVBR5O/
RpQ2KXVnBjLHYdoFGpSD
=YmrV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Brand new to Tomcat
Posted by "Cohen, Laurence" <lc...@novetta.com>.
Thanks for everyone's response. to Andre' Warnier, yes. There are many
ProxyPass statements in nss.conf on the Apache webserver. They appear to
have taken the place of redirect statements in ssl.conf, which is no longer
in use.
Your configuration assumption is correct, except that the users will
connect to the webserver on port 80 and port 443, and it is invisible to
them where they are going on the app server.
Thanks,
Larry
On Tue, Jun 16, 2015 at 12:06 PM, André Warnier <aw...@ice-sa.com> wrote:
> Cohen, Laurence wrote:
>
>> Hi,
>>
>> I find myself in a position where I am the only system administrator on a
>> project that uses tomcat appserver and apache webeserver with a postgres
>> backend.
>>
>
> I am going to do some guesswork here, and you'll tell us if I'm wrong.
>
> Presumably, considering what you are saying above, your actual setup may
> be :
>
> browser <-- --> Apache httpd server front-end <-- --> Tomcat <-- -->
> webapp <-- --> back-end postgres database
>
> So the browser clients actually connect to the Apache front-end server on
> port 80, and the front-end passes some or all of the requests to Tomcat in
> the background.
> (And the users never see a URL which mentions port 8007).
>
> Right/wrong ?
>
> If right, do you know what is the mechanism used in the front-end Apache
> httpd server, to connect to the back-end Tomcat service ?
> Specifically, are there any "ProxyPass" directives in the configuration of
> the front-end Apache server ?
>
>
>
> We have two applications, and before and changeover from mod_ssl
>
>> to mod_nss we were able to go over port 80 to grab files out of the
>> database. The web app in question is listening on port 8007, but proxied
>> on 443. After we switch to mod_nss, something happened with the
>> configuration or the Rewrite Rules, where we can not longer use port 80,
>> although port 443 is working fine.
>>
>> In server.xml I can see the following connector line:
>>
>> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
>> executor="tomcatThreadPool"
>> connectionTimeout="600000"
>> scheme="https" secure="true"
>> clientAuth="false" sslProtocol="TLS"
>> keystoreFile="/opt/dse/keystores/keystore.tomcat"
>> keystorePass="changeit"
>> truststoreFile="/opt/dse/keystores/truststore.jks"
>> truststorePass="password" proxyName="testweb01.novetta.com
>> "
>> proxyPort="443"/>
>>
>> My first question is, can I add another connector line, proxying to port
>> 80
>> as so:
>>
>> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
>> executor="tomcatThreadPool"
>> connectionTimeout="600000"
>> scheme="https" secure="true"
>> clientAuth="false" sslProtocol="TLS"
>> keystoreFile="/opt/dse/keystores/keystore.tomcat"
>> keystorePass="changeit"
>> truststoreFile="/opt/dse/keystores/truststore.jks"
>> truststorePass="password" proxyName="testweb01.novetta.com
>> "
>> proxyPort="80"/>
>>
>> Thanks,
>>
>> Larry Cohen
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Brand new to Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
Cohen, Laurence wrote:
> Hi,
>
> I find myself in a position where I am the only system administrator on a
> project that uses tomcat appserver and apache webeserver with a postgres
> backend.
I am going to do some guesswork here, and you'll tell us if I'm wrong.
Presumably, considering what you are saying above, your actual setup may be :
browser <-- --> Apache httpd server front-end <-- --> Tomcat <-- --> webapp <-- -->
back-end postgres database
So the browser clients actually connect to the Apache front-end server on port 80, and the
front-end passes some or all of the requests to Tomcat in the background.
(And the users never see a URL which mentions port 8007).
Right/wrong ?
If right, do you know what is the mechanism used in the front-end Apache httpd server, to
connect to the back-end Tomcat service ?
Specifically, are there any "ProxyPass" directives in the configuration of the front-end
Apache server ?
We have two applications, and before and changeover from mod_ssl
> to mod_nss we were able to go over port 80 to grab files out of the
> database. The web app in question is listening on port 8007, but proxied
> on 443. After we switch to mod_nss, something happened with the
> configuration or the Rewrite Rules, where we can not longer use port 80,
> although port 443 is working fine.
>
> In server.xml I can see the following connector line:
>
> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
> executor="tomcatThreadPool"
> connectionTimeout="600000"
> scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/opt/dse/keystores/keystore.tomcat"
> keystorePass="changeit"
> truststoreFile="/opt/dse/keystores/truststore.jks"
> truststorePass="password" proxyName="testweb01.novetta.com"
> proxyPort="443"/>
>
> My first question is, can I add another connector line, proxying to port 80
> as so:
>
> <Connector port="8007" protocol="HTTP/1.1" SSLEnabled="true"
> executor="tomcatThreadPool"
> connectionTimeout="600000"
> scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/opt/dse/keystores/keystore.tomcat"
> keystorePass="changeit"
> truststoreFile="/opt/dse/keystores/truststore.jks"
> truststorePass="password" proxyName="testweb01.novetta.com"
> proxyPort="80"/>
>
> Thanks,
>
> Larry Cohen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org