TDI uses both Secure Socket Layer (SSL) and Public Key Infrastructure (PKI) encryption methods. SSL and PKI provides an important foundation for many of the TDI and TDI server features. SSL provides for encryption and authentication of network traffic between two remote communicating parties. Similarly, PKI (public key infrastructure) enables users of unsecured networks to securely and privately exchange data by using a public and a private cryptographic key pair that is obtained and shared through a trusted authority. See Working with certificates.
SSL certificate
An SSL certificate resides on a secure server and is used to encrypt the data that identifies the server. The SSL certificate helps to prove the site belongs to the entity who claims it and contains information about the certificate holder, the domain that the certificate was issued to, the name of the Certificate Authority who issued the certificate, and the root and the country it was issued in.
PKI certificate
A PKI certificate enables users of an unsecured network to add security and privacy to data exchanges. PKI uses a cryptographic key pair that it gets and shares through a trusted authority called a Certificate Authority (CA). Using PKI, we can obtain a certificate that can identify an individual or an organization and directory services that can store the certificates. The CA can also revoke the certificates when necessary. The most common use of a digital certificate is to verify that a user sending a message is who the sender claims to be, and to provide the receiver with the encryption of the reply.
Follow these steps to provide separate configuration options for certificates to be used for PKI Encryption and SSL:
com.ibm.di.server.encryption.keystore com.ibm.di.server.encryption.key.alias api.keystore.password api.key.password
com.ibm.di.server.keystore ----- > api.keystore com.ibm.di.server.key.alias ------>api.key.alias
Theidisrv.sth file now holds the password only for the encryption file.
Using TDI, we can PKI encrypt sensitive properties in the global.properties or in the solution.properties file. One method of decrypting PKI-encrypted properties is to use the Configuration Editor (CE) properties editor. The CryptoUtils command-line utility is another method of decrypting PKI-encrypted properties files. Decryption requires you to give your PKI credentials so that unauthorized users cannot access sensitive information We can properties files that contain PKI encrypted properties using CryptoUtils. see The TDI Encryption utility.
Someone who wishes to send an encrypted message applies for a digital certificate from a CA. The CA issues an encrypted digital certificate that contains the applicant's public key and a other identification data. The CA makes reveals its own public key through printed media or perhaps on the Internet. The recipient of an encrypted message uses the CA's public key to decode the digital certificate attached to the message, verifies the certificate as issued by the CA, and then gets the sender's public key and identification data from the certificate. With this information, the recipient can send an encrypted reply.
Digital certificates are of two types:
CA-signed certificates are signed by a Certificate Authority such as VeriSign and thawte. A self-signed certificate is an identity certificate that is signed by its own creator.
Certificate authority signed certificates
Certificate authorities such as VeriSign require a procedure whereby applicants can prove their identities and obtain certificates that authenticate both the identity of the certificate applicants and its own identity as a signer of a certificate.
Self-signed certificates
Typically there is a local certification authority (CA), that is, the certificates do not come from any of the well known CAs like VeriSign, and so on. The local CA itself should have a root certificate issued by a well-known CA, but even this is not always true. If the local CA's root certificate is self-signed, import it into the truststore of each server or client that is using SSL.
In this case, each server for an SSL connection, and each client doing PKI authentication, generates its own self-signed certificate. It is then necessary to export the certificate to a file and to import it into various truststores. If a client C connects to a server S, C must have S's self-signed certificate in its truststore. If a client C does PKI authentication (symmetric SSL) to a server S, S must have C's self-signed certificate in its truststore. Note: Self-signed certificates can be used for either a client or a server certificate. See the Manage keys, certificates and keystores on information how to do this. Each server for an SSL connection and each client doing PKI authentication must then issue a request for a certificate to the local CA, and must add the resulting certificate into its keystore.
TDI provides separate configuration options for certificates to be used for public key infrastructure (PKI) encryption and Secure Socket Layer (SSL) connection. Independent configuration of PKI and SSL certificates allows us to migrate your encrypted properties separately from the process of upgrading your SSL certificates.
Under PKI, a Certificate Authority (CA) binds public keys to user identities. The user identity must be unique for each CA. Public Key certificates collect each user, user identity, public key, their binding, validity conditions, and other attributes that are made unforgetable in public key certificates issued by the CA.
The certificates used for SSL may expire, or for security reasons, SSL certificates may have to be refreshed frequently. Certificates used for PKI encryption can be persisted longer than it is appropriate to persist SSL certificates. PKI certificates should be maintained in case there is data that has been encrypted using the public key certificate. As a result, TDI allows us to configure PKI and SSL certificates separately. Each server for an SSL connection and each client performing PKI authentication must issue a request for a certificate to the local CA, and must add the resulting certificate into its keystore.
These properties are added to the global.properties file:
com.ibm.di.server.encryption.keystore com.ibm.di.server.encryption.key.alias
These properties variables are set to the same values as the ones already in global.properties:
api.keystore=truststore api.key.alias=server