[ic] Secure server FAQs [monthly posting]

maillist interchange-users@interchange.redhat.com
Thu Mar 14 00:48:01 2002


On Wed, 13 Mar 2002 23:42:23 -0500
"D Zhang - msi" <dzhang@mtspring.com> wrote:

> >     First of all, it is questionable business practice to not certify your
> >     secure server. Besides violating the terms of use of many certificate
> >     issuers, customers notice the changed domain and it is proven by user
> >     surveys and long experience that you will receive fewer orders as a
> >     result. Certs can be obtained for $125 US per year, less than the
> >     typical cost of one hour of a top consultant's time. Do your business
> >     a favor -- spend the money to get a cert.
> 
> I can't agree with the above point of view.
> 
> I wish that ic would not become a guaranteed revenue source of certifying
> companies.
> 

If I don't see SSL, I won't buy at all. If I see SSL but uncertified I have no guarantee, that who I am dealing with is even an existing company. They can take my credit card information and order plenty of services in the internet with it and I have to run and fix it. So I go and rather choose someone else who I can make responsible if something goes wrong.
If you don't use a certificate you definitly hurt your business and probably for more than $125.

Why should web hosting only cost $150/year? Because the competition is high.
Wait for a while until all the smaller CAs are getting recognized by the browsers. I actually saw certificates for $99. How much will be justified for a certificate? How about the security of their systems.
Someday we will probably get them for $50.
How much were the first CD players?

> $125/year is a big deal. Recently, I searched the internet for hosting
> services. There are many servers offering about $150/year, with capacity
> more than enough to run interchange cart. Think of this, those servers have
> to take carry of your site for whole year. How much time, work, and cost
> does it take to issue an certificate?  It got to be fair to every one.
> 
> David
> 
> 
> 
> ----- Original Message -----
> From: "Mike Heins" <mheins@redhat.com>
> To: <interchange-users@chevelle.interchange.redhat.com>
> Sent: Saturday, March 09, 2002 9:18 PM
> Subject: [ic] Secure server FAQs [monthly posting]
> 
> 
> > These are the FAQs:
> >
> >   Shopping cart is dropped when using SSL.
> >
> >     This is a thorny question. It has many possible causes, and most often
> >     occurs when you try to use a different secure server domain than the
> >     regular catalog runs on. (See the next question for more info on
> that.)
> >
> >     If your secure domain is the same as the non-secure domain, it is
> >     usually due to the user not having cookies enabled. It can be due to
> the
> >     HostnameLookups (Stronghold/Apache parameter) not matching for the two
> >     servers, secure and non-secure. It can also be caused by the user
> having
> >     different web proxy addresses for HTTP and HTTPS. If it still does not
> >     work, try changing some of the appropriate configuration parameters in
> >     interchange.cfg:
> >
> >        DomainTail   No
> >        IpHead       Yes
> >
> >     If you still are having problems, try this combination in catalog.cfg,
> >     the catalog configuration file:
> >
> >        SessionExpire  10 minutes
> >        WideOpen       Yes
> >
> >     The above setting will typically make Interchange work when it is
> >     possible to work. Sometimes when you have multiple Interchange servers
> >     sharing the same secure server, you will have problems after accessing
> >     the second one. (The first one issues a session ID cookie, and that
> >     causes problems).
> >
> >   I have a different secure server domain. Why does the shopping cart
> >   get dropped?
> >
> >     First of all, it is questionable business practice to not certify your
> >     secure server. Besides violating the terms of use of many certificate
> >     issuers, customers notice the changed domain and it is proven by user
> >     surveys and long experience that you will receive fewer orders as a
> >     result. Certs can be obtained for $125 US per year, less than the
> >     typical cost of one hour of a top consultant's time. Do your business
> >     a favor -- spend the money to get a cert.
> >
> >     If you insist on doing it anyway, probably driven by the fact that
> >     you need a dedicated IP address for a secure server, you can use the
> >     solutions in the previous FAQ question and get some relief.
> >
> >     But by far the best way is to have all orders and shopping cart calls
> go
> >     only to the secure domain.  Your users may get a different session
> when
> >     browsing the non-secure catalog pages, but it will matter little.
> >
> >     To do this on the Foundation demo, place in catalog.cfg:
> >
> >             AlwaysSecure  order ord/basket ord/checkout
> >
> > A more complete list might be:
> >
> > AlwaysSecure <<EOF
> > account
> > change_password
> > customerservice
> > login
> > logout
> > new_account
> > ord/basket
> > ord/checkout
> > order
> > process
> > query/check_orders
> > query/order_detail
> > query/order_return
> > returns
> > saved_carts
> > ship_addresses
> >         EOF
> >
> > (Thanks to John Beima for the above list.)
> >     Add pages of your own that need to be sure of coherent
> > session information.
> >
> >     For all *forms* to be secure, make sure "process" is on that list.
> (Your search
> >     forms will still be non-secure if you use "[process-search]" to
> produce
> >     the form ACTION.)
> >
> >     To make individual order links secure, use this instead of "[order]":
> >
> >             <A HREF="[area
> >                         href=order
> >                         secure=1
> >                         form='mv_order_item=SKU_OF_ITEM'
> >     ]">Order it</A>
> >
> >     To make a form-based order button secure, use "[process secure=1]" as
> >     the ACTION.
> >
> >   My images aren't there on the secure server!!!
> >
> >     You have a different document root, or the permissions are not such
> >     that you can access them. You can set a different base URL for images
> >     with:
> >
> > ImageDirSecure   https://your.secure.server/somewhere/images
> >
> >     Don't try to set it to an http:// URL -- images will be broken anyway.
> >
> >   My secure pages fail when my browser is MSIE.
> >
> >     MSIE has several SSL bugs, particularly in V5.01.  See the
> C<Apache-SSL>
> >     or C<mod_ssl> FAQ. You can sometimes fix this with an httpd.conf
> change:
> >
> >        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
> >
> > --
> > Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
> > phone +1.513.523.7621 fax 7501 <mheins@redhat.com>
> >
> > For a successful technology, reality must take precedence over public
> > relations, for Nature cannot be fooled. -- Dick Feynman
> >
> > _______________________________________________
> > interchange-users mailing list
> > interchange-users@interchange.redhat.com
> > http://interchange.redhat.com/mailman/listinfo/interchange-users
> >
> >
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users