tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave North" <Dave.No...@signiant.com>
Subject RE: wacky HTTPS->HTTP re-direct problem w/apache and tomcat 4
Date Tue, 22 Jan 2002 12:09:58 GMT
Hi Denny,
	Just tried that - no joy.  It then complains about the
webAppDeploy lines being an invalid serverName.

Cheers

Dave

-----Original Message-----
From: Denny Chambers [mailto:dchambers@snapserver.com]
Sent: Monday, January 21, 2002 4:52 PM
To: Tomcat Users List
Subject: Re: wacky HTTPS->HTTP re-direct problem w/apache and tomcat 4


Have you tried it with out the ServerName directive set in the
<VirtualHost _default_:443> directive?


"Chambers, Norman (Denny)" wrote:
> 
> If tomcat and apache are running on the try using localhost:8080 here:
> 
> WebAppConnection myconn warp ottas13a.ott.signiant.com:8008
> 
> Also do you have the ServerName and Port directive set in the
> httpd.conf? The directives are required by SSL.
> 
> Dave North wrote:
> >
> > sure.  Actually, back in the mailing list archive I just found
someone
> > who had the exact same problem...no solution alas.
> >
> > The server.xml file is the bog standard one with no changes from a
> > tomcat install.
> >
> > My httpd.conf info (basically the standard mod_ssl config with the
> > webAppDeploy stuff bolted in):
> >
> > ##
> > ## SSL Virtual Host Context
> > ##
> >
> > <VirtualHost _default_:443>
> >
> > #  General setup for the virtual host
> > DocumentRoot "/usr/local/apache/htdocs"
> > ServerName ottas13a.ott.signiant.com
> > ServerAdmin root@ottas13a.ott.signiant.com
> > ErrorLog /usr/local/apache/logs/error_log
> > TransferLog /usr/local/apache/logs/access_log
> >
> > #   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:+eNULL
> >
> > #   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 /usr/local/apache/conf/ssl.crt/server.crt
> > #SSLCertificateFile /usr/local/apache/conf/ssl.crt/server-dsa.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 /usr/local/apache/conf/ssl.key/server.key
> > #SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server-dsa.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 /usr/local/apache/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 /usr/local/apache/conf/ssl.crt
> > #SSLCACertificateFile /usr/local/apache/conf/ssl.crt/ca-bundle.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 /usr/local/apache/conf/ssl.crl
> > #SSLCARevocationFile /usr/local/apache/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 require
> > #SSLVerifyDepth  10
> >
> > #   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 CompatEnvVars:
> > #     This exports obsolete environment variables for backward
> > compatibility
> > #     to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold
2.x.
> > Use this
> > #     to provide compatibility to existing CGI scripts.
> > #   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 +FakeBasicAuth +ExportCertData +CompatEnvVars
+StrictRequire
> > <Files ~ "\.(cgi|shtml|phtml|php3?)$">
> >     SSLOptions +StdEnvVars
> > </Files>
> > <Directory "/usr/local/apache/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 /usr/local/apache/logs/ssl_request_log \
> >           "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
> >
> > # DN for tomcat
> > WebAppConnection myconn warp ottas13a.ott.signiant.com:8008
> > WebAppDeploy examples myconn /examples/
> > WebAppDeploy signiant myconn /signiant/
> > WebAppInfo /webapp-info
> >
> > </VirtualHost>
> >
> > -----Original Message-----
> > From: Denny Chambers [mailto:dchambers@snapserver.com]
> > Sent: Monday, January 21, 2002 4:10 PM
> > To: Tomcat Users List
> > Subject: Re: wacky HTTPS->HTTP re-direct problem w/apache and tomcat
4
> >
> > I have this same setup working with out any problems. Can you send
the
> > section of the httpd.conf where you setup the https server. In
tomcat
> > are you using both the http connector and the warp connector? Not
sure
> > if this would cause a problem or not, I am only using the warp
connector
> > by itself.
> >
> > Dave North wrote:
> > >
> > > Hello all,
> > >         I have the following config:
> > >
> > > apache 1.3.2.2 using mod_ssl and mod_webapp
> > > tomcat 4.0.1
> > > RH Linux 7.1
> > >
> > > I had successfully configured apache to talk via the warp
connector to
> > > tomcat for our JSP application.  Now I wanted to add SSL support
so I
> > > downloaded and installed mod_ssl.  No problems so far.  However,
when
> > I
> > > go to https://myhost/myapp/ it fails because it's re-directed me
to
> > > http://myhost:443/myapp/index.jsp.  I have the same problem with
the
> > > examples.  When served from tomcat directly (in http, no problems.
> > >
> > > I can't seem to find anything on this problem and it's driving me
> > crazy!
> > > :)
> > >
> > > Snippet from my httpd.conf:
> > >
> > > # DN for tomcat
> > > WebAppConnection myconn warp localhost:8008
> > > WebAppDeploy examples myconn /examples/
> > > WebAppDeploy myapp myconn /myapp/
> > > WebAppInfo /webapp-info
> > >
> > > I'm just using the standard server.xml for tomcat.
> > >
> > > Any help is MUCH appreciated.
> > >
> > > Cheers
> > >
> > > Dave
> > >
> > > Dave North
> > > SIGNIANT Inc.
> > > Trusted Data Transfer Services
> > > www.signiant.com
> > > Phone: 613-761-3623
> > > Fax: 613-761-3629
> > > EMail: dnorth@signiant.com
> > >
> > > --
> > > To unsubscribe:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > > For additional commands:
<mailto:tomcat-user-help@jakarta.apache.org>
> > > Troubles with the list:
<mailto:tomcat-user-owner@jakarta.apache.org>
> >
> > --
> > To unsubscribe:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands:
<mailto:tomcat-user-help@jakarta.apache.org>
> > Troubles with the list:
<mailto:tomcat-user-owner@jakarta.apache.org>
> >
> > --
> > To unsubscribe:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands:
<mailto:tomcat-user-help@jakarta.apache.org>
> > Troubles with the list:
<mailto:tomcat-user-owner@jakarta.apache.org>
> 
> --

> 
> --
> To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>

--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message