Understanding the Secure Server Settings:

SSL is a Secure Server issue. The QuikStore scripts will "use" the SSL server to process "through" it but it does not create the SSL. This is a very sophisticated encryption process between the secure server and the users browser.

To process through the SSL, the user is sent through this secure server where the certificate resides in order to access the files. In our case, the quikstore.cgi program. This only happens after they leave the View Cart page and open the shipping form. This form, and all others after that, are then encrypted between the user and the server.

You can turn this on by opening the Configuration Editor (Step 2 of the Main Menu) and going to the "Secure Server" tab.

Mirrored vs. Remote Secure Servers:

¤ Mirrored Secure Server

We recommend you choose a hosting company which can or does use the technique described below for their secure server setups. Many do and it can save hours of grief by just finding a hosting company who does. If you don't, just be aware that your problems with directory structures, duplicate files and mismatched configuration settings don't necessarily become our problems without purchasing installation time on a per server basis. QuikStore will run on a remote secure server without any problems, but it does double the complexity of the installation just by the fact it is now running on two totally separate machines. We literally have hundreds of installations which run this way with no problem, but they were initially much more confusing to troubleshoot.

This is how a "mirrored SSL site" is set up:

1) In our example secure server domain "https://www.securecertificatename.com" , you will have your hosting company create a "virtual" or "alias" directory called "store1". This secure domain may use your "secure server certificate" domain name or the hosting company's "secure server certificate" domain name. It doesn't matter to the QuikStore program files which is used. This "secure server certificate" domain name is almost always installed to the server where your web site files are physically stored.

Again, the "store1" virtual directory is not a physical directory for this domain, but merely a pointer as set in step 2 below.

2) You set the physical directory path for the "https://www.securecertificatename.com/store1" virtual directory to the root directory path of your "store1" domain. For our example, the "store1" root (physical) directory path is:

/home/store1/www/

Thus "http://www.store1.com" has the same root directory (physical) path as "https://www.securecertificatename.com/store1", which is again:

/home/store1/www/

Now when you make a call to the secure server domain + the "store1" sub-directory name "https://www.securecertificatename.com/store1" via a browser, it will reference the files in:

/home/store1/www/

The same idea applies when you use your browser to call:

https://www.securecertificatename.com/store1/cgi-bin/quikstore.cgi

The browser will be locked in SSL mode and you will be using the files from the

/home/store1/www/cgi-bin/quikstore.cgi

Thus, calling the secure url "https://www.securecertificatename.com/store1/cgi-bin/quikstore.cgi" runs the same script as calling to http://www.store1.com/cgi-bin/quikstore.cgi.

3) Practical Example

Here is a real world example of a functioning "mirrored" web site. We will use our own web site, since it too is set up this way.

The url "http://www.quikstore.com/" calls to the physical directory:

/home/quikstore/www

The url "https://www.clss.com/quikstore/" also calls to the physical directory:

/home/quikstore/www

...just like "store1" in the above discussion.

For our web site, we have another level of "mirroring". The cgi-bin directory is "mirrored" separately.

The url "http://www.quikstore.com/cgi-bin" calls to the physical directory:

/home/quikstore/www/cgi-bin

The url "https://www.clss.com/cgi-quikstore" also calls to the physical directory:

/home/quikstore/www/cgi-bin

Just the same concept applied again. So "http://www.quikstore.com/cgi-bin/quikstore/quikstore.cgi" calls to the same QuikStore script file as "https://www.clss.com/cgi-quikstore/quikstore/quikstore.cgi". Take a look as you "test order" something from our web site. When you go to the shipping page, the url changes but the same quikstore.cgi file is being accessed.

Very easy to use when the server is set to do "mirrored" SSL. The "Secure Server" tab of our Configuration Editor (Step 2 in the Main Menu) is set up as follows:

• Use Secure Server = Yes
• Post to Remote Server = No
• Secure Script URL = https://www.clss.com/cgi-quikstore/quikstore/quikstore.cgi
• Secure Pages URL = https://www.clss.com/quikstore

And that is all it takes for it to run securely.

¤ Remote Secure Server

A Remote secure server means that you are posting the order to a completely different server than the one the the store runs under normally. When you are using a remote secure server you need a copy of all of the files under the local cgi-bin directory, which is located under 'server_files' in the directory where you installed QuikStore, on the secure server as well as on the non-secure server. This makes debuging a little harder, since there are two sets of files running on different servers.

The "Secure Server" tab of the Configuration Editor (Step 2 in the Main Menu) may be set up as follows:

• Use Secure Server = Yes
• Post to Remote Server = Yes
• Secure Script URL = https://www.secure.server.com/quikstore/cgi-bin/quikstore.cgi
• Secure Pages URL = https://www.secure.server.com/quikstore