SSL is an encryption system used on servers to ensure privacy when transmitting information across the World Wide Web. SSL-enabled servers encrypt sensitive data into ciphertext before sending it to clients, preventing third parties from reading the data, even if it is intercepted en route. Clients receiving data from the server then decrypt the ciphertext to read the data. The use of SSL on a Web server helps ensure that information transmitted between a client, such as a Web browser and a server, such as a Web server, remains private, and enables the clients to authenticate the identity of the server.
For a server and client to use SSL for secure communications, the server must have a public-private key pair and a certificate. The server uses its private key to sign messages to clients. The server sends its public key to clients so these clients can verify that the signed messages are actually from the server and so they can encrypt messages to the server. The server then decrypts these messages with its private key.
To send its public key to clients, the server needs a certificate issued by a certificate authority (CA). The certificate contains a server public key, the Distinguished Name associated with the server certificate, the serial number or issue date of the certificate, and the expiration date of the certificate.
A certificate authority (CA) is a trusted third party (or a designated internal authority) that issues certificates. The CA verifies the identity of the server and digitally signs the certificate with its private key and uses its public key to ensure that the certificate is valid. A signed certificate binds server identity to a pair of electronic keys, used to encrypt and sign digital information. The certificate is signed with the certificate authority's private key, to verify server identity.
To operate a Web server in secure SSL mode, you must first obtain a signed certificate for your system, from a certificate authority. VeriSign, Inc. is one of a number of companies that acts as a certificate authority. However, you can use a signed certificate of the appropriate format from any certification authority.
When you set up secure connections, your public key must be associated with a digitally signed certificate from a certificate authority (CA), designated as a trusted CA on your server.
This section provides an overview of security concepts.
The rapid growth of electronic commerce over the Internet has led to an increasing demand for secure network communications. In addition, intra-company communications over private networks often contain confidential information that needs protection.
A secure network communication has the following characteristics:
Encryption in its simplest form is scrambling a message so that it cannot be read until unscrambled by the receiver. The sender uses an algorithmic pattern, or key to scramble, or encrypt the message. The receiver has the decryption key. Encryption ensures privacy and confidentiality in transmissions sent over the Internet.
The Secure Sockets Layer (SSL) protocol uses both asymmetric and symmetric key exchange. Asymmetric keys are used for the SSL handshake. During the handshake, the master key, encrypted with the receiver's public key, is passed from the client to the server. The client and server make their own session keys using the master key. The session keys are used to encrypt and decrypt data for the remainder of the session. Symmetric key exchange is used during the exchange of the cipher specification or encryption level.
The server needs a digital certificate to send its public key to clients. This certificate is issued by a certificate authority (CA), who verifies the identity of the server.
CAs broadcast their public key and Distinguished Name bundled together so that people will add them to their Web servers and browsers as a trusted CA certificate. When you designate the public key and certificate from a CA to be a trusted CA certificate, your server trusts anyone who has a certificate from that CA. You can have many trusted CAs as part of your server. The HTTP Server includes several default trusted CA certificates. You can add or remove trusted CAs using the IBM Key Management Utility included with your server.
To communicate securely, the receiver in a transmission must trust the CA who issued the sender's certificate. This situation is true whether the receiver is a Web server or browser. When a sender signs a message, the receiver must have the corresponding CA-signed certificate and public key designated as a trusted CA certificate.
A Public Key Infrastructure (PKI) is a system of digital certificates, certificate authorities, registration authorities, certificate management service, and X.500 directories that verify the identity and authority of each party involved in an Internet transaction. These transactions can be financial, or can involve any operation where identity verification is required, such as confirming the origin of proposal bids or author of e-mail messages.
A PKI supports the use of Certificate Revocation Lists (CRLs). A CRL is a list of certificates that have been revoked. CRLs provide a more global method for authenticating a client's identity by certificate, and can verify the validity of trusted CA certificates.
CRLs and trusted CA certificates are stored and retrieved from an X.500 directory server. The protocols used for storing and retrieving information from an X.500 directory server are Directory Access Protocol (DAP) and Lightweight Directory Access Protocol (LDAP). The HTTP Server supports LDAP.
You can distribute information on multiple directory servers over the Internet and intranets, allowing an organization to manage certificates, trust policy, and CRLs from either a central location, or in a distributed manner. This capability makes the trust policy more dynamic because you can add or delete trusted CAs from a network of secure servers, without having to reconfigure each of the servers.
The Secure Sockets Layer (SSL) protocol was developed by Netscape Communications Corporation. SSL ensures that data transferred between a client and a server remains private. This protocol allows the client to authenticate the identity of the server. SSL Version 3 is required to authenticate the identity of a client.
Once your server has a digital certificate, SSL-enabled browsers like Netscape Navigator and Microsoft Internet Explorer can communicate securely with your server, using SSL. With SSL, you can easily establish a security-enabled Web site on the Internet, or on your private intranet. A browser that does not support HTTP over SSL cannot request URLs using HTTPS. The non-SSL browsers will not allow submission of forms that require secure communications.
SSL uses a security handshake to initiate a secure connection between the client and the server. During the handshake, the client and server agree on the security keys they will use for the session and the algorithms they will use for encryption. The client authenticates the server; optionally, the server can request the client certificate. After the handshake, SSL is used to encrypt and decrypt all the information in both the HTTPS request and the server response, including:
HTTPS is a unique protocol that combines SSL and HTTP. You need to specify https:// as an anchor in HTML documents that link to SSL-protected documents. A client user can also open a URL by specifying https:// to request an SSL-protected document.
Because HTTPS (HTTP + SSL) and HTTP are different protocols and use different ports (443 and 80, respectively), you can run both SSL and non-SSL requests simultaneously. This capability enables you to provide information to users without security, while providing specific information only to browsers making secure requests. This functionality enables a retail company on the Internet to allow users to look through their merchandise without security, but then fill out order forms and send their credit card numbers using security.