SSL Server Certificates | Electronic Commerce (Charles River Media Networking/Security)

The practical means of implementing PKI and digital signatures are via Web server certificates that enable authentication and SSL encryption. SSL certificates form the basis of an Internet trust infrastructure by allowing Web sites to offer safe, secure information exchange to their customers. SSL server certificates satisfy the need for confidentiality, integrity, authentication, and nonrepudiation.

SSL Defined

SSL, originally developed by Netscape Communications, is an information technology for securely transmitting information over the Internet. The SSL protocol has become the universal standard on the Web for authenticating Web sites to Web browser users, and for encrypting communications between browser users and Web servers.

Server certificates are available from CAs (such as VeriSign)—trustworthy, independent third parties that issue certificates to individuals, organizations, and Web sites. CAs use thorough verification methods to ensure that certificate users are who they claim to be before issuing them. CA’s own self-signed SSL digital certificates are built into all major browsers and Web servers, including Netscape Communicator and Microsoft Internet Explorer, so that simply installing a digital certificate on a Web server enables SSL capabilities when communicating with Web browsers. SSL server certificates fulfill two necessary functions to establish e-commerce trust: SSL server authentication and SSL encryption.

SSL Server Authentication

Server certificates allows users to confirm a Web server’s identity. Web browsers automatically check that a server’s certificate and public ID are valid and have been issued by a CA included in the list of trusted CAs built into browser software. SSL server authentication is vital for secure e-commerce transactions in which users, for example, are sending credit card numbers over the Web and first want to verify the receiving server’s identity.

SSL Encryption

SSL server certificates establish a secure channel that enables all information sent between a user’s Web browser and a Web server to be encrypted by the sending software and decrypted by the receiving software—thus protecting private information from interception over the Internet. In addition, all data sent over an encrypted SSL connection is protected with a mechanism for detecting tampering—that is, for automatically determining whether the data has been altered in transit. This means that users can confidently send private data, such as credit card numbers, to a Web site, trusting that SSL keeps it private and confidential.

How SSL Server Certificates Work

SSL certificates take advantage of SSL to work seamlessly between Web sites and visitors’ Web browsers. The SSL protocol uses a combination of asymmetric public key encryption and faster symmetric encryption. (See sidebar, “SSL Server Certificates Steps” for more information.)

The Netscape Navigator and Microsoft Internet Explorer browsers have built-in security mechanisms to prevent users from unwittingly submitting their personal information over insecure channels. If a user tries to submit information to an unsecured site (a site without an SSL server certificate), the browsers will, by default, show a warning.

In contrast, if a user submits credit card or other information to a site with a valid server certificate and an SSL connection, the warning does not appear. The secure connection is seamless, but visitors can be sure that transactions with a site are secured by looking for the following cues:

The URL in the browser window displays “https” at the beginning, instead of http.
In Netscape Communicator, the padlock in the lower-left corner of the Navigator window will be closed instead of open.
In Internet Explorer, a padlock icon appears in the bar at the bottom of the IE window^[1].

SSL Strengths: 40-Bit and 128-Bit SSL

SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the session key generated by every encrypted transaction. The longer the key, the more difficult it is to break the encryption code. 128-bit SSL encryption is the world’s strongest; according to RSA Labs, it would take a trillion years to crack using today’s technology. 128-bit encryption is approximately 3 X 1026 stronger than 40-bit encryption.

Microsoft and Netscape offer two versions of their Web browsers, export and domestic, that enable different levels of encryption depending on the type of SSL server certificate with which the browser is communicating. First, 40-bit SSL server certificates (such as VeriSign’s SSL Certificates) enable 40-bit SSL when communicating with export-version Netscape and Microsoft Internet Explorer (IE) browsers (used by most people in the U.S. and worldwide) and 128-bit SSL encryption when communicating with domestic-version Microsoft and Netscape browsers. Second, 128-bit SSL server certificates (such as VeriSign’s Global Server IDs) enable 128-bit SSL encryption (the world’s strongest) with both domestic and export versions of Microsoft and Netscape browsers.

SSL Server Certificates Steps

The process begins by establishing an SSL “handshake”—allowing the server to authenticate itself to the browser user, and then permitting the server and browser to cooperate in the creation of the symmetric keys used for encryption, decryption, and tamper detection:

A customer contacts a site and accesses a secured URL—a page secured by an SSL certificate (indicated by a URL that begins with “https:” instead of just “http:” or by a message from the browser). This might typically be an online order form collecting private information from the customer, such as address, phone number, and credit card number or other payment information.
The customer’s browser automatically sends the server the browser’s SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
The server responds, automatically sending the customer’s browser the site’s digital certificate, along with the server’s SSL version number, cipher settings, and so on.
The customer’s browser examines the information contained in the server’s certificate, and verifies that:
1. The server certificate is valid and has a valid date.
2. The CA that issued the server has been signed by a trusted CA whose certificate is built into the browser.
3. The issuing CA’s public key, built into the browser, validates the issuer’s digital signature.
4. The domain name specified by the server certificate matches the server’s actual domain name.
If the server cannot be authenticated, the user is warned that an encrypted, authenticated connection cannot be established.
If the server can be successfully authenticated, the customer’s Web browser generates a unique “session key” to encrypt all communications with the site using asymmetric encryption.
The user’s browser encrypts the session key itself with the site’s public key so that only the site can read the session key, and sends it to the server.
The server decrypts the session key using its own private key.
The browser sends a message to the server informing it that future messages from the client will be encrypted with the session key.
The server then sends a message to the client informing it that future messages from the server will be encrypted with the session key.
An SSL-secured session is now established. SSL then uses symmetric encryption (which is much faster than asymmetric PKI encryption) to encrypt and decrypt messages within the SSL-secured “pipeline.”
After the session is complete, the session key is eliminated.

It all takes only seconds and requires no action by the user^[1].

In order to fully enable 128-bit encryption with a Global Server ID, it’s important to generate the right kind of private key during the process of obtaining an SSL certificate. An important step in the process is generating a Certificate Signing Request (CSR) within the Web server software. In generating a CSR, Web server administrators should be careful to select a 1024-bit private key, which enables the Global Server ID to establish 128-bit SSL encryption, rather than a 512-bit private key, which enables only 40-bit encryption.

Netscape users can follow these steps to see what level of encryption is protecting their transactions:

Go to the secure Web page you want to check.
Click the Security button in Navigator’s toolbar. The Security Info dialog box indicates whether the Web site uses encryption.
If it does, click the Open Page Info button to display more information about the site’s security features, including the type of encryption used.

You can also check to see which level of SSL is activated on your Web server by following these steps:

Using a 128-bit client, such as the domestic version of Netscape Navigator, click Options/Security Preferences.
Under the Enable SSL options, click Configure for both SSL 2 and SSL 3. Make sure acceptance for the 40- and 56-bit encryption ciphers are turned off.
Try to access the site. If it using less than 128 bit security, then you will receive an error in your browser window: “Netscape and this server cannot communicate securely because they have no common encryption methods^[1].”

IE users can find out a Web site’s encryption level by following these steps:

Go to the Web site you want to check.
Right-click on the Web site’s page and select Properties.
Click the Certificates button.
In the Fields box, select Encryption type. The Details box shows you the level of encryption, 40-bit or 128-bit. (See the following section for more information about SSL encryption levels.)^[1].

E-businesses may choose to simplify the process of certificate checking for site visitors by describing the security measures they have implemented in a Security and Privacy statement on their sites. For example, sites that use VeriSign SSL Certificates can also post the Secure Site Seal on their home page, security statement page, and purchase pages. The Seal is a widely recognized symbol of trust that enables site visitors to check certificates in real time from VeriSign with one click.

SGC and 128-Bit Step-Up

To ensure that strong, 128-bit encryption protects e-commerce transactions for all users, businesses should install 128-bit IDs, such as VeriSign’s Global Server IDs, on their servers. However, the export browsers that permit only 40-bit encryption with 40-bit SSL server certificates will allow strong, 128-bit encryption when interacting with 128-bit server certificates because these certificates are equipped with a special extension that enables Server Gated Cryptography (SGC) for Microsoft browsers and “International Step-Up” for Netscape browsers.

The extension enables 128-bit encryption with export-version browsers by prompting two “handshakes” when a user’s browser accesses a page protected by a Global Server ID. When an export-version Netscape or Microsoft browser connects to the Web server, the browser initiates a connection with only a 40-bit cipher. When the server certificate is transferred, the browser verifies the certificate against its built-in list of approved CAs. Here, it recognizes that the server certificate includes the SGC or International Step-Up extension, and then immediately renegotiates the SSL parameters for the connection to initiate an SSL session with a 128-bit cipher. In subsequent connections, the browser immediately uses the 128-bit cipher for full-strength encryption.

Securing Multiple Servers and Domains with SSL

As organizations and service providers enhance their Web sites and extranets with newer technology to reach larger audiences, server configurations have become increasingly complex. They must now accommodate:

Redundant server backups that allow Web sites and extranets to maximize site performance by balancing traffic loads among multiple servers
Organizations running multiple servers to support multiple site names
Organizations running multiple servers to support a single site name
Service providers using virtual and shared hosting configurations^[1]

But, in complex, multiserver environments, SSL server certificates must be used carefully if they are to serve their purpose of reliably identifying sites and the businesses operating them to visitors and encrypt e-commerce transactions—thus, establishing the trust that customers require before engaging in e-commerce. When used properly in an e-commerce trust infrastructure equipped with multiple servers, SSL server certificates must still satisfy the three requirements of online trust:

Client applications, such as Web browsers, can verify that a site is protected by an SSL server certificate by matching the “common name” in a certificate to the domain name (such as www.verisign.com) that appears in the browser. Certificates are easily accessible via Netscape and Microsoft browsers.
Users can also verify that the organization listed in the certificate has the right to use the domain name, and is the same as the entity with which the customer is communicating.
The private keys corresponding to the certificate, which enable the encryption of data sent via Web browsers, are protected from disclosure by the enterprise or ISP operating the server^[1].

The Certificate Sharing Problem

In order to satisfy the requirements of Internet trust, one SSL server certificate can be used to secure each domain name on every server in a multiserver environment, and the corresponding private keys can be generated from the hosting server. Some enterprises or ISPs practice certificate sharing, or using a single SSL server certificate to secure multiple servers. Organizations use certificate sharing in order to secure backup servers, to ensure high-quality service on high-traffic sites by balancing traffic among several servers, or, in the case of ISPs and Web hosts, to provide inexpensive SSL protection to price-sensitive customers. However, as described next, certificate-sharing configurations do not satisfy the fundamental requirements of Internet trust.

VeriSign Recommendations for Implementing SSL on Multiple Servers

Now, let’s look at some common shared certificate configurations for an e-commerce trust infrastructure:

Fail-safe backup: Redundant servers, not used simultaneously.

Load balancing: Multiple sites with different common names on multiple servers.

Load balancing: Multiple sites with the same common name on multiple servers.

ISP shared SSL: One certificate issued to an ISP’s domain, used on multiple servers by multiple Web sites.

Name-based virtual hosting: An ISP or Web Host provides each hosted customer with a unique domain name, such as customername.isp.com^[1].

Fail-Safe Backup

Certificate sharing is permissible. However, when the backup server is not under the same control as the primary server, the private key cannot be adequately protected, and a separate certificate should be used for each server.

Load Balancing: Multiple Sites with Different Common Names

To prevent browsers from detecting that the URL of the site visited differs from the common name in the certificate, a different certificate should be used for each server/domain name combination. A different certificate should also be used to protect the security of private keys.

Load Balancing: Multiple Sites with the Same Common Name

Instead of jeopardizing private key functionality by copying the key for multiple servers, a different certificate should be used for each server. Each certificate may have the same common name and organizational name, but slightly different organizational unit values.

ISP Shared SSL

ISP shared SSL prevents site visitors from verifying that the site they are visiting is the same as the site protected by the certificate and listed in the certificate itself. Each site’s server should have its own certificate. Or, merchants must inform their customers that site encryption is provided by the ISP, not the merchant, and the ISP must guarantee the services of all the hosted companies whose sites use shared SSL.

Name-Based Virtual Hosting

If the same certificate is used for each domain name, browsers will indicate that the site domain name does not match the common name in the certificate. To solve this problem, a “wildcard” certificate of the form *.isp.com is required to properly serve the multi-hostname configuration without creating browser mismatch error messages.

Next, let’s examine the second key component of an Internet trust infrastructure: secure online payment management.