Most users can't connect to our SSL-- help!

From: Jason/Midheaven (jason@midheaven.com)
Date: 04/23/02


From: Jason/Midheaven <jason@midheaven.com>
Date: Mon, 22 Apr 2002 15:52:54 -0700

Hi all--

Hopefully some wonderful guru will step up to the plate w/an easy
solution to our ongoing woes, as our server tech people have given up!

Below is our amassed & ongoing "trouble ticket", which describes the
problem fairly thoroughly.

Beneath *that*, I've included all relevant SSL settings from our
httpd.conf file. Long breaks/omissions indicated by:
#######################

...but I've tried to include all relevant <VirtualHost> wrapper tags.

*Any* help, hints, suggestions will be MOST appreciated!

Please send 'em to <jason@midheaven.com> if possible--

TIA!!

#######################

Subject: Large percentage of customers cannot connect to https:

As per above. Customers report that they click the link to the secure
server, which then grinds indefinitely.
 Here's how one technically inclined customer described it to us:
 "2) Your secure order form is not working. The https link does not
connect, and I even tried to telnet to port 443 of your server and it
wasn't responding. Tried this from two separate computers on two
separate networks."
 The problem is ongoing, chronic, & we're losing lots of business from
it (and it's creating lots of extra work as we fax & phone cc#'s back &
forth). We cannot re-create the problem here (the secure orderform
always seems to load), but we really, really must get to the bottom of
this ASAP--
 Thanks!
 PS-- Please cc: jason@midheaven.com on the response to this

      At 01/23/2002 06:02 PM we wrote - Hello, It's not clear from
your ticket which domain you're having trouble with. Could you let us
know which domain is the problem? Thanks!
 Tim Keene Rackspace Customer Support

 At 01/23/2002 07:11 PM you wrote -
 midheaven.com-- that's the only domain we have set up, as far as I
know.
 Here's the exact link which is giving so many people problems:
 https://www.midheaven.com/bin/secureorderform.cgi
 that's the only secure "page" on our site-- always seems to work fine
for us, as I've said.
 ***VERY IMPORTANT*** I need to be cc:'ed at <jason@midheaven.com> on
all tickets, or be told how to make this happen. Currently, e-mails are
going to Paul's home computer e-mail address, & he's going on vacation
for a week. Paul was looking into this too, so perhaps he's already set
it up--
 Thanks!

 At 01/24/2002 12:07 PM we wrote - I checked your site from my system
and from my home system, but I'm not able to replicate the error. The
only thing I could find that leads me to believe anything is configured
incorrectly is in the error log:
 [Wed Jan 9 17:59:45 2002] [error] mod_ssl: SSL handshake failed (server
midheaven.com:443, client 66.92.179.50) (BSAFE-SSL-C librar y error
follows) [Wed Jan 9 17:59:45 2002] [error] BSAFE-SSL-C:
error:14095412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
[Hint: Subje ct CN in certificate not server name or identical to CA!?]
[Fri Jan 18 13:25:53 2002] [error] [client 66.92.179.50] user sturgeon:
authentication failure for "/orders/": password mismatch [Wed Jan 23
15:21:58 2002] [error] [client 66.92.179.50] user sturgeon:
authentication failure for "/orders/": password mismatch
 However, the errors generated here are very sporadic - as if one or two
users are unable to connect. I'm going to have another technician
examine this as a second opinion, just to be sure I didn't miss anything.

 Tim Keene Rackspace Customer Support

 At 01/24/2002 05:09 PM we wrote - Since I too was unable to recreate
this issue, I can not be absolutely certain what the exact issue is.
What I do suspect though, is that the problem you are seeing is with
people who are using older browsers for the SSL transactions.
 A very detailed explanation of the problem and the fixes for the
problem is contained here:
 http://www.modssl.org/docs/2.6/ssl_faq.html#io-ie
 What I did on your server's Apache configuration was to add the
SSLCipherSuite option and append the SetEnvIf for browser handling with
the site (basically tells the server to respond to SSL transactions when
the older browser connects to the machine.
 I believe that the changes made will resolve *most* of the
problems...but not exactly all as if my guess is correct, the problem is
with people using older browsers...which is hard to fully account for
*every* type of old browser (including those that just do not have ssl
support).
 Please let me know if you have any other concerns or require further
assistance.
 Kind Regards, Adam McCarthy

 At 02/07/2002 01:38 PM you wrote -
 Hi--
 Unfortunately, the issue doesn't seem to be solved-- it's been
especially bad the last few days, even, so while the patch no doubt did
some good, the key problem remains.
 Without exeception, the customers I've spoken to who are having this
problem:
 a) are using IE5 or Netscape 4.7 or better; b) report that when they
click on the link: https://www.midheaven.com/bin/secureorderform.cgi
that their browser "grinds" for several minutes (attempting to load
w/nothing loading), then eventually comes back w/a "Page cannot be
displayed" message.
 This would seem to indicate some sort of overloaded server or network
bottleneck issue. Perhaps, I don't know, but I answer about 3 such
complaints every day, & that's just the customers who bothered to
complain.
 I've used SSL technology on many of the sites I've worked on over the
years; this is the only major & chronic problem I've experienced w/it.
We've really got to get to bottom of this somehow. Our customer
confidence is really hurting in the quarters that are effected by this--
 Thanks!

 At 02/07/2002 01:49 PM we wrote - As mentioned earlier, there is no
clear, universal fix for all browsers in regards to handling the SSL
certificate. Although the last changes helped, the problem is still
occurring. The only other course of action I can think of would be to
get another certificate, that only uses 40 bit encryption, as the
problem you are seeing is mainly caused by how some of these browsers
handle higher levels of encryption.
 Past this, I cannot think of many other sokutions, other than moving to
a different SSL backend such as Raven SSL, etc. Again I do apologize for
the trouble you are having, but this problem is mainly with the client
side of the transaction rather than a server-side issue, and as such
there is not a whole lot that can be done to correct the problems people
are having with browser versions that use poor SSL implementation.
 Kind Regards, Adam McCarthy

 At 02/13/2002 12:52 PM you wrote -
 Hi Adam--
 Well, I guess we need to look into 40-bit encryption or Raven SSL--
which, do you think, would be most likely to provide relief for our
customers who can't connect?

 At 02/14/2002 10:59 AM we wrote - I have also added a couple of
additonal directives to the httpd.conf to see if any further imporvement
can be made.
 At approximately line 1323 of the httpd.conf file (outside of the
VirtualHost directives), I have added the following:
 SSLSessionCache dbm:/var/cache/httpd/ssl_cache SSLSessionCacheTimeout
300
 These line should resolve some issues with the SSL handshakes initiated
by the client machines in addition to the other directives I applied
previously. After doing a little more research on the issue, I realized
I forgot to add these directives as well. Basically these directives
should eliminate/reduce uneccessary session handshakes and speed up
response times between the client request and the server.
 If the problems you are having still persist, I would advise looking
into getting a 40 bit certificate rather than switching to a different
SSL platform, for a couple of reasons:
 (1)The 40 bit certificate is going to be as good as it gets, if other
clients still cannot connect, there is almost nothing else that can be
done
 (2)Switching to RavenSSL would be odd since vbery few technicians here
work with it, which would make SSL related issues involving RaveNSSL
either unsupported or fee-based.
 Please let me know if you require furhter assistance on this issue.
 Kind Regards, Adam McCarthy

 
 At 02/19/2002 02:37 PM you wrote -
 Hi Adam--
 Well, we'll def. need to be looking into getting the 40-bit
certificate-- if you've got any hints on that, please let us know. I
think Paul will want you guys to install it, too, as he didn't sound up
to another certificate install (I know that means $$).
 The problem is, apparently, much worse than we thought. Last Thursday I
added a line to the secure orderform script which basically just lets us
know, when the order comes through, that it was placed on the secure
orderform. Previously, we had no way of telling whether the orders were
placed securely or insecurely.
 As of today, not a single order (apart from my test order, when I
updated the script) has come through on the secure server.
 We've received probably around 100 orders since then; and, as usual,
numerous complaints that the secure orderform won't load.
 There has to be some solution to this mystery-- you guys can access the
secure server, we can access it from here, but apparently no one else in
the whole wide world can.
 Our certificate is up for renewal in March anyway, so please send any
40-bit certificate recommendations our way. This would clearly seem to
be the next step; if that doesn't work, I don't know what we'll do.
 Thanks!

 At 02/19/2002 03:03 PM we wrote - I will forward this incident to an
account manager so that he can get the certificate ordering process
underway and all other details. Once this issue becomes an
implementation issue, the support team will carry things from there.
 Kind Regards, Adam McCarthy

 At 04/04/2002 06:32 PM you wrote -
 Following installation of 40 bit certificate, we still are experiencing
the same problem. However, I'm disappointed to say that there's been no
discernable improvement on this end. We are still getting roughly the
same number of complaints from our customers that the upgrade/downgrade
to 40-bit encryption has not improved our customers' ability to connect
to our https:// server. It's hard to say exactly what the percentage
is, but I'd estimate there's about a 75 to 90% failure rate, if
customer email is any indication.
 The failures do not consistently result in 404 codes, so our web logs
are not much assistance in figuring out who's unable to connect, or in
what quantity, and/or what their browser configuration is.
 Obviously, for an e-commerce site, we are losing business as a result
of this ongoing unresolved issue, and this is an unacceptable
situation.

 At 04/05/2002 10:00 PM we wrote - I have added some configuration
options to your SSL virtualhost which have worked well for me in the
past when dealing with issues such as this. In the past, every time I
have seen something like this happen, it was due to clients using older
browsers that are not fully compatible with modern SSL implementations.
If you continue to have problems, please provide *exact* version
information for the browser being used .. there are subtle differences
between versions that can make this work or not work. I have connected
to your server using the following browsers without error:
 Lynx Version 2.8.4rel.1 (17 Jul 2001) (Linux) w3m version w3m/0.3
(Linux) Elinks 0.4pre2 (Linux) Konqueror 2.2.2 (Linux) galeon 1.2.0
(Linux) Mozilla 0.9.9 (Linux) Netscape Communicator 4.77 (Linux) MSIE
6.0.2600.0000 (Win2k Server) Mozilla 0.9.9 (Win2k Server) Netscape
6.2.2 (Win2k Server)
 Since your site works fine on such a variety of web browsers on
multiple operating systems and platforms, this leads me to believe this
is actually a client-side problem. I would recommend telling your
clients to upgrade to the latest version of whatever browser they use to
see if this resolves the issue. While this may be inconvenient, it truly
is the best solution. Eventually there will be a time when the SSL
standards will change so much that these older browsers will fail 100%
of the time, and there will be nothing that can be done on the server to
alleviate the problem.
 Regards, Henry Pugsley Rackspace Managed Hosting Support

 At 04/08/2002 08:05 PM you wrote -
 We are getting unencrypted orders from longtime customers who state
(this is a quote)
 "Secure order form still will not load, despite a new, fresh machine
w/IE6..."
 This is not merely anecdotal evidence. Many customers are describing
their setups/browsers as current, and reporting that they can securely
connect to other ecommerce sites.
 In the past week since the 40 bit certificate downgrade we have gotten
over 100 orders. Only one came in via https, the rest were done on our
http page. It's hard to say how much business we're losing, but it's
significant.
 At this point I'm ready to give up and begin shopping for another
server. I really don't know where else to turn at this point. I can't
imagine other online resellers have this sort of failure rate for
customers attempting to connect via https.

 At 04/08/2002 10:25 PM we wrote - After conferring with several of my
colleagues, the only option left that can be done from the server side
would be to use OpenSSL on your server instead of the proprietary
BSAFE/SecureWeb SSL implementation you are using. The problem with this
is your server is rather old, and the SSL implementations are so
different, that the conversion may cause more problems than it might
fix.
 A safe way to test this would be to put another server online, running
Redhat 7.2 with OpenSSL, then move just your SSL site(s) to this server
for testing. We may be able to put the server up free of charge for a
couple weeks, but I will have to confer with my team leader before I can
say for sure. The test server will probably be:
 Redhat 7.2 650Mhz Duron Processor 256MB RAM 18GB SCSI Hard Drive
 If turns out the SSL works fine on the new server, we can do a couple
of things:
 1. Keep the test server in a minimal configuration and just put your
SSL sites on it. The minimal configuration would probably be around
$200/mo.
 2. Upgrade the server so it can replace your current server, then
migrate all of your sites to the new server and take the old server
offline. For a configuration faster than your current server, your
monthly would be less than $880 (800Mhz proc, 512MB RAM, 18GB SCSI,
30GB/mo bandwidth, 20GB SCSI DAT Tape, weekly backup, Netscreen 5).
 The new motherboards can handle processors up to 1Ghz and up to 1.5GB
of RAM, so you will have plenty of room to upgrade in the future with
either option. Personally I prefer the first option, since it allows you
to more flexibility and you can spread the load over two servers.
 I will speak with my team leader tomorrow about getting the test server
online. The prices I listed are probably a little high .. your account
manager can give you more accurate prices, but we will worry about the
pricing after we find out if the server works or not. As always, feel
free to contact support if you have any questions about this.
 Thanks, Henry Pugsley Rackspace Managed Hosting Support

...none of which has helped any!

#######################

#<IfDefine SSL>
LoadModule ssl_module modules/libssl.so
#</IfDefine>

#######################

#<IfDefine SSL>
AddModule mod_ssl.c
#</IfDefine>

#######################

##
## SSL Support
##
## When we also provide SSL we have to listen to the
## standard HTTP port (see above) and to the HTTPS port
##
<IfDefine SSL>
Listen 80
Listen 443
</IfDefine>

#######################

##
## 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
#
<IfDefine SSL>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
</IfDefine>

<IfModule mod_ssl.c>

# 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 either `none'
# or `dbm:/path/to/file' for the mechanism to use and
# second the expiring timeout (in seconds).
#SSLSessionCache dbm:/var/cache/ssl_scache
SSLSessionCache shm:/var/cache/ssl_scache(512000)
SSLSessionCacheTimeout 300

# Semaphore:
# Configure the path to the mutual explusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex file:/var/run/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.
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

# Logging:
# The home of the dedicated SSL protocol logfile. Errors are
# additionally duplicated in the general error log file. Put
# this somewhere where it cannot be used for symlink attacks on
# a real server (i.e. somewhere where only root can write).
# Log levels are (ascending order: higher ones include lower ones):
# none, error, warn, info, trace, debug.
SSLLog logs/ssl_engine_log
SSLLogLevel warn

</IfModule>

<IfDefine SSL>

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot /home/pashby/sites/midheaven.com/htdocs
#ServerName new.host.name
ServerAdmin root@localhost
ErrorLog /var/log/httpd/error_log-ssl
TransferLog /var/log/httpd/access_log-ssl

# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine off

# 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 /etc/httpd/conf/ssl.crt/server.crt
#SSLCertificateKeyFile /etc/httpd/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 /etc/httpd/conf/ssl.key/server.key
#SSLCertificateKeyFile /etc/httpd/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 @@ServerRoot@@/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/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 @@ServerRoot@@/conf/ssl.crl
#SSLCARevocationFile @@ServerRoot@@/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.
# 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'.
# 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.
# 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.
# 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.
# OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when
SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire

# 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:
# 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.
# 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.
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>

#######################

<VirtualHost 209.61.158.122:443>
ServerName www.midheaven.com
ServerAlias midheaven.com
ServerAdmin root@midheaven.com
DocumentRoot /home/pashby/sites/midheaven.com/htdocs
#CustomLog /home/pashby/sites/midheaven.com/logs/access_log combined
ScriptAlias /cgi-bin/ /home/pashby/sites/midheaven.com/cgi-bin/
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/midheaven.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key

## Added by RS-HP 04-05-2002 ##
#SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
ssl-unclean-shutdown
BrowserMatch "MSIE 5\." nokeepalive downgrade-1.0 force-response-1.0
ssl-unclean-shutdown
## END ##

## IE SSL error workarround ##
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

ErrorLog /home/pashby/sites/midheaven.com/logs/error_log
<Directory /home/pashby/sites/midheaven.com/htdocs/bin>
Options ExecCGI
AddHandler cgi-script .cgi .pl
</Directory>
<Directory /home/pashby/sites/midheaven.com/htdocs>
AllowOverride All
</Directory>

#User paul
<Directory "/home/pashby/sites/midheaven.com/htdocs/fi/Images">
Options FollowSymLinks
</Directory>
<Directory "/home/pashby/sites/midheaven.com/htdocs/revolverusa">
</Directory>
AddHandler server-parsed .shtml
</VirtualHost>
ScriptLog /home/pashby/sites/midheaven.com/logs/cgi-log
#AddType application/x-pn-mpegurl .m3u

#############################################################
# Added to try and correct certificate issues Adam@rackspace#
#############################################################
SSLSessionCache dbm:/var/cache/httpd/ssl_cache
SSLSessionCacheTimeout 300



Relevant Pages

  • Most users cant connect to our SSL-- help!
    ... I've included all relevant SSL settings from our ... Subject: Large percentage of customers cannot connect to https: ... server, which then grinds indefinitely. ... "2) Your secure order form is not working. ...
    (comp.security.ssh)
  • Most users cant connect to our SSL-- help!
    ... I've included all relevant SSL settings from our ... Subject: Large percentage of customers cannot connect to https: ... server, which then grinds indefinitely. ... "2) Your secure order form is not working. ...
    (comp.security.unix)
  • Re: Antw: Re: LDAP Authentication Problem
    ... TLSv1 und wird auf einen SSL Client Hello Request mit TLSv1 nicht ... antworten anstatt ein SSLv3 Server Hello. ... the LDAP PAM module and the shadow package. ...
    (de.comp.sys.novell)
  • Re: ModSSL - Knoppix 3.3
    ... NameVirtualHosts and SSL don't mix. ... This automatically pushes an incorrect http request to the secure host over ... > I create some server key & crt. ...
    (Focus-Linux)
  • RE: php4
    ... Mod_php4 only gets loaded if you define SSL. ... Of course I restarted apache after the install... ... # Based upon the NCSA server configuration files originally by Rob McCool. ... Not all browsers support this. ...
    (freebsd-newbies)