Secure sockets layer communication
The industry-standard Secure Sockets Layer (SSL) protocol, which uses signed digital certificates from a certificate authority (CA) for authentication, is used to secure communication in a Tivoli Identity Manager Express deployment.
SSL provides encryption of the data that is exchanged between the applications. Encryption makes data that is transmitted over the network intelligible only to the intended recipient.
Signed digital certificates enable two applications connecting in a network to authenticate each other’s identity. An application acting as an SSL server presents its credentials in a signed digital certificate to verify to an SSL client that it is the entity it claims to be. An application acting as an SSL server can also be configured to require the application acting as an SSL client to present its credentials in a certificate, thereby completing a two-way exchange of certificates. Signed certificates are issued by a third-party certificate authority for a fee.
Some utilities, such as those provided by OpenSSL, can also issue signed certificates.
SSL uses public key encryption technology for authentication. In public key encryption, a public key and a private key are generated for an application. Data encrypted with the public key can only be decrypted using the corresponding private key. Similarly, the data encrypted with the private key can only be decrypted using the corresponding public key. The private key is password-protected in a key database file (keystore) so that only the owner can access the private key to decrypt messages that are encrypted using the corresponding public key.
Digitally-signed CA certificates
A signed digital certificate is an industry-standard means of verifying the authenticity of an entity, such as a server, client, or application. To ensure maximum security, a certificate is issued by a third-party certificate authority (CA).
CA certificate chaining
To increase security, some organizations use CA certificate chaining.
Self-signed certificates
You can use self-signed certificates to test an SSL configuration before you create and install a signed certificate issued by a certificate authority.
Certificate file types
Certificates and keys are stored in several types of files.
SSL implementations that Tivoli Identity Manager Express uses
Tivoli Identity Manager Express uses several implementations of the SSL protocol.
SSL tools that Tivoli Identity Manager Express uses
Tivoli Identity Manager Express uses several SSL key management utilities.
SSL authentication
The SSL authentication process uses certificates that are issued by a certificate authority. The same process applies if the certificates are issued by an certificate generation utility or if self-signed certificates are used.
Digitally-signed CA certificates
A signed digital certificate is an industry-standard means of verifying the authenticity of an entity, such as a server, client, or application.
To ensure maximum security, a certificate is issued by a third-party certificate authority (CA).
A certificate-authority certificate (CA certificate) must be installed to verify the origin of a signed digital certificate.
When an application receives another application’s signed certificate, it uses a CA certificate to verify the originator of the certificate.
A certificate authority can be well-known and widely used by other organizations, or local to a specific region or company. Many applications, such as Web browsers, are configured with the CA certificates of well known certificate authorities to eliminate or reduce the task of distributing CA certificates throughout the security zones in a network.
A certificate contains the following information to verify the identity of an entity:
Organizational informationThis section of the certificate contains information that uniquely identifies the owner of the certificate, such as organizational name and address.
You supply this information when you generate a certificate using a certificate management utility.Public keyThe receiver of the certificate uses the public key to decipher encrypted text sent by the certificate owner to verify
its identity. A public key has a corresponding private key that encrypts the text.Certificate authority’s distinguished nameThe issuer of the certificate identifies itself with this information.
Digital signatureThe issuer of the certificate signs it with a digital signature to verify its authenticity. This signature is compared to the signature on the corresponding CA certificate to verify that the certificate originated from a trusted certificate authority.
Web browsers, servers, and other SSL-enabled applications generally accept as genuine any digital certificate that is signed by a trusted Certificate Authority and is otherwise valid.
For example, a digital certificate can be invalidated because it has expired or the CA certificate used to verify it has expired, or because the distinguished name in the digital certificate of the server does not match the distinguished name specified by the client.
SSL authentication
The SSL authentication process uses certificates that are issued by a certificate authority. The same process applies if the certificates are issued by an certificate generation utility or if self-signed certificates are used.
Figure 1 illustrates
the steps that authenticate the identity of an application:
Figure 1. Authenticating the identity of an application
To establish an SSL connection:
1.An application acting as an SSL client contacts an application acting as an SSL server.
2.The SSL server responds by sending the signed certificate stored in its keystore to the SSL client. A CA certificate contains identifying information about the CA that issued the certificate and the application (owner) that presents the certificate, a public key, and the digital signature of the CA.
3.The SSL client uses the corresponding CA certificate stored in its keystore to verify the digital signature on the certificate.
4.In addition to verifying the signature on the certificate, the SSL client requests the SSL server to prove its identity.
5.The SSL server uses its private key to encrypt a message.
6.The SSL server sends the encrypted message to the SSL client.
7.To decrypt the message, the SSL client uses the public key embedded in the signed certificate it received, and thereby verifies the identity of the owner of the certificate.
If the SSL server is set to use two-way SSL authentication (client authentication), it then asks the SSL client to verify and prove its identity, and the same process described above is used to verify the identity of the SSL client to the SSL server.
One-way SSL authentication
One-way SSL authentication enables the application operating as the SSL client to verify the identity of the application operating as the SSL server.
Two-way SSL authentication
In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.
Configuration of Apache for SSL between the Client (e.g., browser) and the Web Server
Pre-setup
You need to have the following SSL certificates that which will be used to establish the connection:
? Private key certificate
? Public key certificate or server cert
? Certificate Authority (CA)
In the example that follows, these will be named:
? Private key = rmohanKey.crt
? Public Key = rmohanCert.crt
? CA = rmohanCA.crt
For 2-way SSL, another CA file is needed:
? FrontEndCAwithCAClientChainToAuthenticate.crt
This file is the same as the CA FrontEndCA.crt file but contains, concatenated to it, the CAchain it will need to authenticate the client certs in case of 2-way SSL.
Simple Setup for 1-way SSL
Three properties need to be configured in the Apache httpd.conf file:
?SSLCertificateFile
?SSLCertificateKeyFile
?SSLCACertificateFile.
For example:
# server cert to use
SSLCertificateFile /etc/httpd/conf/ssl.crt/rmohanCert.crt
# server private key to use
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/rmohanKey.crt
# CA to use
SSLCACertificateFile /etc/httpd/conf/rmohanCA.crt
Simple Setup for 2-way SSL
In addition to the above 3 properties, the following properties in the Apache httpd.conf file need to be configured:
?SSLVerifyClient
?SSLVerifyDept
# server cert to use
SSLCertificateFile /etc/httpd/conf/ssl.crt/rmohanCert.crt
# server private key to use
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/rmohanKey.crt
# CA to use
SSLCACertificateFile /etc/httpd/conf/rmohanCA.crt
# Force 2 way SSL
# none: no client Certificate is required at all
# optional: the client may present a valid Certificate
# require: the client has to present a valid Certificate
#optional_no_ca: the client may present a valid Certificate but has not to be (successfully) verifyable.
SSLVerifyClient require
# This directive sets how deeply mod_ssl should verify before deciding that the clients
# don’t have a valid certificate. The depth actually is the maximum number of intermediate
#certificate issuers
SSLVerifyDepth 10
It is assumed that the client CAs to be used to authenticate have been extracted. These CAs need to be concatenated to the SSLCACertificateFile.
If the goal is to propagate the client certificate to WebLogic for authentification, consider adding the option:
SSLExportClientCertificates
# SSLExportClientCertificates : Export client certificates and the certificate chain
#behind them to CGIs. The certificates are base 64 encoded in the
#environment variables SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAIN_n,
# where n runs from 1 upwards.
How to Debug
SSLLog: This directive sets the name of the dedicated SSL protocol engine logfile. Error-type messages are additionally duplicated to the general Apache error log file (directive ErrorLog). Put this somewhere where it cannot be used for symlink attacks on a real server (somewhere where only root can write). For example:
SSLLog /var/httpd/logs/ssl_engine_log
SSLLogLevel: This directive sets the verbosity degree of the dedicated SSL protocol engine logfile. The level is one of the following (in ascending order where higher levels include lower levels):
?none – no dedicated SSL logging is done, but messages of level “error” are still written to the general Apache error logfile
?error – log messages of error type only, i.e. (messages which show fatal situations (processing is stopped). Those messages are also duplicated to the general Apache error logfile
?warn – log also warning messages, i.e., messages which show non-fatal problems (processing is continued)
?info – log also informational messages, i.e. messages which show major processing steps
?trace – log also trace messages, i.e. messages which show minor processing steps
?debug – log also debugging messages, i.e. messages which show development and low-level I/O information
For example:
SSLLogLevel info
Recent Comments