https://www.domain.com/test/secure.html
WebSTAR Server Suite includes SSLv2 and SSLv3 as part of the server. This allows you to serve specific pages which are encrypted when sent to the browser, and any form responses, such as private personal data, are encrypted when they are sent back to the server. To invoke it, simply create URLs that uses the https (secure HTTP) protocol. For example, you can protect a credit card acceptance URL so that the information is automatically encrypted by the browser before it is sent.
WebSTAR SSL includes a full implementation of the Secure Sockets Layer (SSL) protocol, which provides server authentication, data encryption, and message integrity. These combine to keep the HTTP data truly secure as it travels across the Internet.
The Secure Sockets Layer Protocol, developed by Netscape, uses authentication and encryption technology developed by RSA Data Security Inc. For more information about the SSL protocol, see these URLs:
http://www.netscape.com/eng/ssl3/draft302.txt
http://developer.netscape.com/misc/developer/conference/proceedings/cs2/index.html
SSL is layered below application protocols such as HTTP and above TCP/IP. When SSL is implemented in both the client and the server software, all data is encrypted before it is transmitted.
WebSTAR Server Suite SSL supports SSL versions 2 and 3, and is based on the OpenSSL library.
The WebSTAR SSL server uses an ISO X.509 Certificate that is authenticated with RSA public key cryptography (encryption). With public-key cryptography, the server publishes a key and browsers contacting that server encrypt their messages using that public key. Only the server can decrypt the messages, because only the server has the private key. For more information, see:
http://www.rsa.com/rsalabs/newfaq/q3.html
With public key cryptography, the longer the keys, the longer it would take to guess the keys and break the encryption. To break one message encrypted with RC4-40 (WebSTAR SSL's lowest level of encryption), a computer would have to attempt to decrypt the message with about 500 billion different keys. The effort of breaking the encryption of that one message would not apply to any other messages: they would have to be decrypted separately. The 56-bit and 128-bit keys are even more secure, and are used by banks and other institutions.
As of mid-1999, there are legal limits on export of this kind of cryptography from the United States. Therefore, WebSTAR is shipped in two versions: US & Canada with stronger encryption using longer keys, and International version with 40-bit encryption.
The U.S. Domestic version of WebSTAR SSL implements the encryption described below, as well as the options included in the international version.
Although the U.S. government prevents the export of RC4-128 and some versions of DES encryption software, that does not affect the ability of international sites to access a secure server. The server negotiates to the encryption level understood by the accessing browser.
Once you have installed and configured SSL in the WebSTAR Server Suite, clients can connect to the secure server using a URL that starts with https : instead of http :.
The letter "s" at the end of the code "https" indicates that the connection will be secure.
For example the following URL will bring up a secure page (if you replace "domain.com" with your host, and have a file in this path).
Behind the scenes, the browsers automatically connects to the correct port (443), and perform a certificate negotiation. In this phase, the browser sends a message explaining what encryption ciphers it recognizes, and the server uses the strongest cipher it has available. If you have them all enabled, they are evaluated in this order:
You can turn these ciphers on and off in the SSL Security panel (see Encryption Ciphers ), but you can't change the order.
Once it has found the strongest cipher they can both use, the server sends its certificate (proving who the owner is) and uses that to create the encryption key. This makes the secure connection.
Then the browser encrypts data it sends to the server, such as credit card numbers, and decrypts data it gets from the server, such as medical data or bank records.
Browser certificates expire periodically. Some older browsers have already passed their Thawte expiration date and many VeriSign certificates will expire at the end of 1999.
Browsers will report this apparent error to users. They can just tell the browser to accept the certificate, but they may contact you in confusion.
https://www.thawte.com/certs/server/rollover.html
You can add an SSL certificate for each IP number on your server. This does not apply to virtual domains, which are created using the Header routing. In addition, the host name must be specified using an A Name entry in the DNS record: it must not be a CNAME alias.
For information, see Virtual Hosts: Hosting Multiple Web Sites
See also DNS .
However, the certificate authorities generally charge a significant amount of money per host certificate, per year. Therefore, a good solution is to obtain a domain name that, with a relevant host name, will seem appropriate to your clients and online users in the SSL URL. For example, you can get domain name like " secureserver.com" , then you could get a certificate for the host name " safe" , so your shoppers will see a URL like this:
https://safe.secureserver.com/knickknacks/OrderForm.html
Remember that the HTTPS URL will only be used for the few web pages where private data is collected or displayed for verification. It never has to be promoted, remembered or even displayed on a web page, since your SSL pages only need be accessed from a link on another web page.
Some large institutions have authorization power: they can sign internal certificates. Because they are between the Certificate Authority and the server certificate, they are called intermediate certificates .
If you get a certificate in this way, it's part of a certificate chain : It includes not only the "subject" certificate (for your host), but also the root certificates and intermediate certificate information.
For example, a Certificate Authority could sign a certificate for Domain.com that authorized them to sign web server certificates and personal/email certificates. Domain.com could then use that certificate to sign all of their internal SSL server certificates and certificates for their employees.
WebSTAR SSL supports these features, but intermediate certificates are very expensive.
Thawte allows you to generate wildcard certificates, (using an asterisk instead of the host name, as in: *.domain.com ), with WebSTAR Server Suite 4. However many versions of Microsoft Internet Explorer will display an error message to the user when they connect to one of these certificates.
Therefore, you should only use wildcard certificates in circumstances where you are confident that most browsers will be version 4 and later, and you are prepared to reassure people with earlier browsers that their data is truly secure.