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
• Collecting secure data from visitors to your site (e.g., credit card info)
• The Secure Server and Custom Domain Names
• Technical Issues

WebCom customers who utilize the BudgetSite, BusinessSite, and WebCommerce service plans may use the Commerce Server wherever they feel appropriate (use of secure transactions is not included with the PersonalSite Service Plan). 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 rate schedule 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 that 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).

Neither email nor FTP to and from the WebCom server is secure. Therefore, if you use the secure server to collect sensitive information, and your form's configuration instructs the WebCom Form Processor to email the form's data to you, you've defeated the purpose of using the secure form. The data will travel unsecured from the WebCom server to your email box in the email message. Similarly, if you collect sensitive form data in a file, and then retrieve the file via FTP, the entire content of the file is exposed unsecured during the FTP transfer. Please observe the following guidelines and procedures to ensure that secure data collected from visitors to your site is never exposed.

1. Make sure your 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) 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).

Use only an SSL enabled browser (e.g., Netscape) and the secure server URL to retrieve the file, and be sure the file is password protected so only authorized parties can retrieve it.

• If the secure data file resides under your WWW directory, it should be in a password protected directory, so only authorized parties can retrieve it. You can use your SSL enabled (e.g., Netscape) Web browser to retrieve the file using the secure server. Since the file resides 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 the File menu to save the file locally.
• If the secure data file is not under your WWW sub-directory, you'll need to retrieve it using the form processor and the secure server. You'll need a form application which prompts you for a password, and then sends the contents of the file to your browser (using the format screen statement in the form processor, after having confirmed that the entered password was valid). The only difference between this method vs. the previous is that it permits you to store the data outside of your WWW directory. We have created a sample form processor application for this purpose. Visit the Sample Form Processor Application page to see the sample.

Be careful not to lose transactions

After you retrieve your file securely, you'll probably delete it from the WebCom server, so that the 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://secure.your_domain.com/"), an error will be returned to the browser referring to a security "certificate." The reason this occurs is that verification of the host for which the security software was actually purchased (in our case this is "webcom.securesites.net") is part of the security and authentication process. If one clicks on the "Continue" button on the error dialog box, the page will be brought up securely. Unfortunately, there is no way of preventing this error message from appearing, other than using "webcom.securesites.net" in any URLs which use "https."

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. To retrieve a document securely, once again, simply use the ordinary URL with the https server code substituted.

The Netscape Commerce Server does not allow the inclusion of non-secure data on a page retrieved via a secure URL. Therefore, if you're using the commerce server to distribute secure pages, you will need to ensure that all references to inline-graphics in those pages (graphics displayed within your pages, using the IMG SRC tag) use "https" instead of "http". Please note, this is only required for secure pages retrieved via the secure server. A fill-out form does not need to be retrieved via the https secure URL in order to keep user-entered data secure, it only needs to be submitted to the secure URL for 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.

Remember that your account has a much smaller allowance for secure transfers than for unsecure transfers, and the price of secure traffic above your allowance is much higher than unsecure traffic, so please only use the secure server when absolutely necessary.