Terminology and Security Applications for SSL and TLS Certificates
The following table defines the security terms associated with SSL and TLS certificates and applies them to communications sessions between a IBM® Connect:Direct® PNODE (client) and SNODE (server). The terms are listed in alphabetical order.
|CA-Signed Certificate||Digital document issued by a certificate authority that binds a public key to the identity of the certificate owner, thereby enabling the certificate owner to be authenticated. An identity certificate issued by a CA is digitally signed with the private key of the certificate authority.|
|Certificate Authority (CA)||An organization that issues digitally-signed certificates. The certificate authority authenticates the certificate owner's identity and the services that the owner is authorized to use, issues new certificates, renews existing certificates, and revokes certificates belonging to users who are no longer authorized to use them. The CA digital signature is assurance that anybody that trusts the CA can also trust that the certificate that it signs is an accurate representation of the certificate owner.|
|Certificate Signing Request (CSR)||Message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a directory name in the case of an X.509 certificate), and the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information.|
|Key Database||Database generated by the GSKKYMAN utility for
creating and managing public and private keys and certificates. Typically,
the files in this database are password-protected to ensure that they
are inaccessible to unauthorized users.
Note: If System SSL is in FIPS mode, a FIPS keybase is required. See z/OS V1R11.0 Cryptographic Services System Sockets Layer Programming SC24-5901-08.
|Key ring||File that contains public keys, private keys,
trusted roots, and certificates. A key ring is a collection of certificates
that identify a networking trust relationship (also called a trust
policy) and are stored in a database. key rings are associated with
specific user IDs, which can have more than one key ring. Key rings
enable you to share key rings across multiple servers.
Note: If System SSL is in FIPS mode, the key ring might have FIPS requirements. See z/OS V1R11.0 Cryptographic Services System Sockets Layer Programming SC24-5901-08.
|Private Key||String of characters used as the private, “secret” part of a complementary public-private key pair. The asymmetric cipher of the private key is used to sign outgoing messages and decrypt data that is encrypted with its complementary public key. Data that is encrypted with a Public Key can only be decrypted using its complementary Private Key. The private key is never transmitted.|
|Public Key||String of characters used as the publicly distributed part of a complementary public-private key pair. The asymmetric cipher of the public key is used to confirm signatures on incoming messages and encrypt data for the session key that is exchanged between server and client during negotiation for an SSL/TLS session. The public key is part of the ID (public key) certificate. This information is stored in the key certificate file and read when authentication is performed.|
|Self-Signed Certificate||Digital document that is self-issued, that is, it is generated, digitally signed, and authenticated by its owner. Its authenticity is not validated by the digital signature and trusted key of a third-party certificate authority. To use self-signed certificates, you must exchange certificates with all your trading partners.|
|Session Key||Asymmetric cipher used by the client and server to encrypt data. It is generated by the SSL software.|