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 [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > 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: [EMAIL PROTECTED] > > > > -- > > To unsubscribe: <mailto:[EMAIL PROTECTED]> > > For additional commands: <mailto:[EMAIL PROTECTED]> > > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> -- Denny Chambers Quantum Corporation, Inc. Network Attached Storage Division Java Linux Engineer Phone: 251-478-5730 Cell: 251-605-3446 IM: [EMAIL PROTECTED] -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>