Get started quickly with secure connections: IBM HTTP Server
System Administration IBM HTTP Server documentation

SSL

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.

 

Security Concepts

This section provides an overview of security concepts.

What is a secure communication?

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:

Access control

Resources are protected and accessed only by authorized parties. Restricting access on the basis of passwords, IP address, host names, or SSL client authentication ensures access control.

Authenticity

You know who you are talking to and that you can trust that person. Authentication, using digital signature and digital certificates, ensures authenticity.

Information integrity

Messages are not altered while being transmitted. Without information integrity, you have no guarantee that the message you sent matches the message received. Digital signature ensures integrity.

Privacy and confidentiality

Information conveyed from party to party during a transaction remains private and cannot be read, even if it gets into the wrong hands. Encryption ensures privacy and confidentiality.

What is Encryption?

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.

There are two kinds of keys used for encryption:

Asymmetric keys

you create a key pair With asymmetric keys. The key pair consists of a public key and a private key, which are different from each other. The private key holds more of the secret encryption pattern than the public key. Do not share your private key with anyone.

The server uses its private key to sign messages to clients. The server sends its public key to clients so that they can encrypt messages to the server, which the server decrypts with its private key. Only you can decrypt a message that has been encrypted with your public key because only you have the private key. Key pairs are stored in a key database protected by a password.

Symmetric keys

Symmetric keys follow an age-old model of the sender and receiver sharing some kind of pattern. This same pattern is then used by the sender to encrypt the message and by the receiver to decrypt the message.

The risk involved with symmetric keys is that you have to find a safe transportation method to use, when sharing your secret key with the people you want to which you want to communicate.

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.

What is Authentication?

Authentication is the process used to verify identity. There are two ways that the server uses authentication:

Digital signature

A digital signature is a unique mathematically computed signature that ensures accountability. A digital signature is similar to a credit card, on which your photo is displayed. To verify the identity of the person sending you a message, look at the sender's digital certificate.

Digital certificate

A digital certificate, or digital ID, is like having a credit card with a picture of the bank president with his arm around you. A merchant trusts you more because not only do you look like the picture on the credit card, the bank president trusts you, too.

You base your trust of the sender authenticity on whether you trust the third party (a person or agency) that certified the sender. The third party issuing digital certificates is called a certificate authority (CA) or certificate signer.

A digital certificate contains:

  • The public key of the person being certified
  • The name and address of the person or organization being certified, also known as the Distinguished Name
  • The digital signature of the CA
  • The issue date
  • The expiration date

You enter your Distinguished Name as part of a certificate request. The digitally-signed certificate includes your Distinguished Name and the Distinguished Name of the CA.

You can request one of the following certificates:

  • A server certificate to do commercial business on the Internet from VeriSign or some other CA. For a list of supported CAs, see Buying a certificate from an external CA provider.
  • A server certificate that you create for your own private Web network.

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.

What is a Public Key Infrastructure?

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.

What is the Secure Sockets Layer protocol?

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:

  • The URL the client is requesting
  • The contents of any form being submitted
  • Access authorization information, like user names and passwords
  • All data sent between the client and the server

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.

 
Related information...
     (Back to Top)