About The Secure Server

WebCom provides the Netscape Commerce Server, a high performance, industry standard Web server that enables encrypted exchange of information between itself and compatible Web browsers (the Netscape Navigator, for instance). This eliminates the possibility, however small, that someone might capture and view sensitive information (such as credit card numbers, passwords, and confidential documents) while it's enroute over the Internet. Please read this entire page carefully to ensure that you are observing all necessary security measures to guarantee that your sensitive data is never exposed.

• Usage and Pricing Policies
• Making your Forms Secure
• Security Guidelines
• Retrieving Files Securely
• The Secure Server and Custom Domain Names
• Technical Issues

WebCom customers who utilize the BudgetSite, BusinessSite, or WebCommerce service plans may use the Commerce Server wherever they feel appropriate (use of secure transactions is not included with the PersonalSite or NameSaver Service Plans). Usage, however, is charged on a metered basis separately from other network traffic, due to the significant performance overhead required to negotiate an encrypted transaction.

The BudgetSite, BusinessSite, and WebCommerce service plans come with a generous allowance for the exchange of secure information. If you use the secure server only for the submission of forms with sensitive information (such as credit card info), your quota will permit thousands of form transactions with no additional fee. See our rates page for pricing details.

We recommend you use the secure server only when strictly necessary, to keep your fees low. To help you control usage, we recommend you never advertise a secure URL. Advertise URLs to non-secure pages, with links to the secure pages. Typically, the secure server is not used to retrieve documents from the server, but only to submit forms with sensitive information to the server (by setting the action to the secure server as shown below).

There are only two steps involved in making forms secure:

Step One: Configure your form so that it submits data to our system securely. To do this all you need to do is make a minor change to the action portion of the form tag of your form. Instead of using "http://webcom.com/~webcom/cgi-bin/form" simply use "https://webcom.securesites.net/cgi-bin/form". When you have made this change to your form, your forms will be submitted securely.

Step Two: Be sure your form information is only written to a file. The Form Processor allows you to take form information and write it to a file send it to email or display it on your visitor's screen. Of these features, writing data to a file is the only secure option. When you create the configuration file for your order form, only use the file parameter or format file statement to record your order data. You can still use format screen and format email statements for order confirmation, but when you do, do not include sensitive order information. Never use the email parameter ($email=address@isp.ext) as it automatically sends all information to that address. Be sure that your Form Processor application writes to a file in a password protected subdirectory of your www directory, so that it is not accessible by anyone except yourself, and so that you can download it later, securely, using a secure browser.

Once your have received orders you will need to retrieve them from your account. See Retrieving Files Securely below for important information about retrieving sensitive information.

1. Make sure your secure form action is set to the secure server (<FORM METHOD=POST ACTION="https://webcom.securesites.net/cgi-bin/form">)
2. Store the collected data in a file only.
3. Never use FTP or email to deliver the collected data from your WebCom account to another computer (neither at the time the form is submitted nor at any subsequent time), as both those methods are insecure. Use only an SSL browser to retrieve the file, and make sure that the file is password protected (see below) so that only authorized parties can retrieve the file.
4. Under all circumstances make sure the FTP permissions on the file containing the sensitive data are set to not publicly readable (see our FTP file permissions help if you need help on this).

Important! When retrieving order files or other files containing sensitive information from your WebCom Account, use only an SSL enabled browser (e.g., Netscape) and the secure server URL to retrieve the file. It is also recommend that the file be placed in a password protected directory so only authorized parties can retrieve it.

As long as your secure data file resides under your www directory, you can access it securely over the web using the secure server URL. Access the file using https://webcom.securesites.net/userid/securedirectory/file.txt instead of just http://webcom.com/~webcom/userid/securedirectory/file.txt. If the file is in a password protected directory, you will be required to enter a valid userid and password, and then the file will be securely transmitted to your browser, at which time you can use your browser's File menu to save the file locally.

Be careful not to lose transactions

After you retrieve your file securely, you'll probably delete it from the WebCom server, so that next time you retrieve it, it will only contain new transactions since the last time you retrieved it. However, if you're not careful, there's a small possibility that you could lose transactions.

Suppose that immediately after you retrieve the file, but before you delete the file, somebody submits your form and a new transaction is appended to the file. When you delete the file, you've lost the new transaction. To prevent this scenario, follow the following procedure when retrieving your file:

1. Use your FTP client to first rename the data file
2. Retrieve the renamed data file securely (using your secure browser - as described above)
3. Delete the renamed data file with your FTP client or the WebCom File Manager (Note: you do not need to recreate the original data file, as the Forms Processor will recreate it with the next form submission)

If a custom domain name is used in a URL accessing the Secure Server (i.e. "https://[anything].your_domain.com/"), The secure server will not work. You must use "webcom.securesites.net" along with "https://" in order for the secure server to work.

The Netscape Commerce Server uses the Secure Sockets Layer (SSL) Protocol to encrypt communications between the client and server. It is addressed using the "https" URL form. For example: <FORM ACTION="https://webcom.securesites.net/cgi-bin/form"> tells the Web browser to post a form using the secure server (whereas to post the same form to the non-secure server you'd use the just "http" instead of "https" at the beginning of the URL, and "www" instead of "secure"). To retrieve a document securely, simply use the "https://webcom.securesites.net/userid/[path to file]..." instead of the normal URL.

The name of the secure server is "webcom.securesites.net". If you want a transaction to be secure, it not only needs to use https, but also needs to reference "webcom.securesites.net".

Your browser is very careful when it comes to secure data, and will give warning messages to the viewer if there are inconsistancies in the security of the data. Errors can also occur when you link to a file without explicitly stating the filename. (Such as linking to the main page of a directory.) To prevent these errors, always use full URLS when making links from secure pages. For example, when linking, instead of using "http://webcom.com/~webcom/userid/" use "https://webcom.securesites.net/userid/index.html".

The Server does not allow the inclusion of non-secure data on a page retrieved via a secure URL. Therefore, if you're using the secure server to display secure pages, you will need to ensure that all references to inline-graphics (graphics displayed within your pages, using the IMG SRC tag) use "https" instead of "http", and "webcom.securesites.net" instead of your domain name or "webcom.com/~webcom".

(Note that this is only required for secure pages retrieved via the secure server. A fill-out form does not need to be retrieved via the secure server in order to keep user-entered data secure, it only needs to be submitted securely to the form processor (https://webcom.securesites.net/cgi-bin/form), and thus it can contain inline graphics without the secure URL. Only in rare cases where you're delivering a secure document to the browser, and the document contains inline graphics, do you need to be sure that the inline graphics are addressed with the secure URL as well.)