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 [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]> > > -- > > -- > 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]>