IV. SSL Server Certificates
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 websites to offer safe, secure information exchange to their customers. SSL server certificates satisfy the need for confidentiality, integrity, authentication and nonrepudiation.

A. SSL Defined
Secure Sockets Layer (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 websites to Web browser users and for encrypting communications between browser users and Web servers.

Server certificates are available from Certificate Authorities (CAs) such as VeriSign - trustworthy, independent third parties that issue certificates to individuals, organisations and websites. 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 fulfil two necessary functions to establish e-commerce trust:

  • SSL server authentication: Server certificates allow 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 certificate authority (CA) - such as VeriSign - 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, 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 website, trusting that SSL keeps it private and confidential.

B. How SSL Server Certificates Work
SSL Certificates take advantage of SSL to work seamlessly between websites and visitors' Web browsers. The SSL protocol uses a combination of asymmetric public key encryption and faster symmetric encryption.

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:

  1. A customer contacts a site and accesses a secured URL: a page secured by a 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.

  2. 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.

  3. The server responds, automatically sending the customer's browser the site's digital certificate, along with the server's SSL version number, cipher settings etc.

  4. 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 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.

  5. 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.

  6. 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.

  7. The server decrypts the session key using its own private key.

  8. The browser sends a message to the server informing it that future messages from the client will be encrypted with the session key.

  9. The server then sends a message to the client informing it that future messages from the server will be encrypted with the session key.

  10. 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."

  11. Once the session is complete, the session key is eliminated.

It all takes only seconds and requires no action by the user.

The Netscape Navigator and the 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 show a warning by default:

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 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, which enable different levels of encryption depending on the type of SSL server certificate with which the browser is communicating.

  • 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 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.
  • 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.

In order to fully enable 128-bit encryption with a Global Server ID, it is 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 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 the Navigator toolbar. The Security Info dialogue box indicates whether the website 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 the Netscape Navigator, click on Options/Security Preferences.
  • Under the enable SSL options, click on 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."

IE users can find out a website's encryption level by following these steps:

  • Go to the website you want to check.
  • Right-click on the website 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).

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. Sites that use VeriSign SSL Certificates can also post the Secure Site Seal on their homepage, security statement page and purchase pages. The Seal is a widely recognised symbol of trust that enables site visitors to check certificates in real time from VeriSign with one click (see "VII. The VeriSign Advantage" below for more information about the Seal).

2. 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 enable "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 recognised 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.

C. Securing Multiple Servers and Domains with SSL
As organisations and service providers enhance their websites and extranets with newer technology to reach larger audiences, server configurations have become increasingly complex. They must now accommodate:

  • Redundant server backups that allow websites and extranets to maximise site performance by balancing traffic loads among multiple servers
  • Organisations running multiple servers to support multiple site names
  • Organisations running multiple servers to support a single site name
  • Service providers using virtual and shared hosting configurations

However, 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 - 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:

  1. 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).
  2. Users can also verify that the organisation 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.
  3. 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
VeriSign recommends that, to satisfy the requirements of Internet trust, one SSL server certificate be used to secure each domain name on every server in a multi-server environment and that the corresponding private keys be generated from the hosting server.

Some enterprises or ISPs practice certificate sharing or use a single SSL server certificate to secure multiple servers. Organisations use certificate sharing in order to secure back-up servers, 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 in the following section, certificate-sharing configurations do not satisfy the fundamental requirements of Internet trust.

2. VeriSign Recommendations for Implementing SSL on Multiple Servers
Here are some common shared certificate configurations and VeriSign's recommendations for addressing them to most effectively reinforce an e-commerce trust infrastructure:

Fail-Safe Backup: Redundant servers, not used simultaneously
Certificate sharing is permissible. However, when the back-up 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 on multiple servers
To prevent browsers from detecting that the URL of the site visited differs from the common name in the certificate and to protect the security of private keys, a different certificate should be used for each server/domain name combination.

Load Balancing: Multiple sites with the same common name on multiple servers
Instead of jeopardising 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 organisational name but slightly different organisational unit values.

ISP Shared SSL: One certificate issued to an ISP's domain, used on multiple servers by multiple Web sites
This 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: An ISP or Web Host provides each hosted customer with a unique domain name, such as customername.isp.com.
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. (VeriSign offers wildcard certificates on a case-by-case basis and they are subject to certain additional licensing terms and conditions. For more information, please contact shared-ssl@verisign.com.)

For a complete explanation of VeriSign's solutions for securing multiple Web server and domain configurations, please see our white paper at http://www.verisign.com/rsc/wp/certshare/certshare.pdf.

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

Previous Page Previous Page Next Page Next Page
[an error occurred while processing this directive]